Attention is currently required from: Hoernchen, laforge, osmith.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email )
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
Patch Set 2:
(13 comments)
File doc/manuals/chapters/ipc_if.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/991159a7_ebbfb5e5
PS2, Line 42: Once connected, _osmo-trx-ipc_ will submit a `GREETING_REQ` message primitive
> (The whole description of the IPC messages could be done with mscgen and diag graphs, like we do in […]
Yeah, it can be improved later on. It's not like the whole procedure is super complex anyway.
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/0de3cd0d_23702d30
PS2, Line 113: @closed@
> this gets printed literally as @closed@ in the pdf, I guess it should be monospace `closed` instead?
I'll use __ since it's not some keyword in the code.
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/b85b8c1b_a259221b
PS2, Line 116: TIP: See
> Maybe move this TIP to the start of the section? Then the reader could open it next to this document […]
I think it's fine having it at the end, otherwise I have the feeling you are redirecting too much the user when entering a section.
But no strong opinion with it though. I think I'll leave it as it is for now.
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/158ec7df_3a7446fd
PS2, Line 170: +w
> missing space
Ack
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/6448d3ca_9a33af92
PS2, Line 171: +w
> missing space
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/09410d55_ee9996eb
PS2, Line 223: ``
> `
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/e31b8e86_9516cc96
PS2, Line 226: ``
> `
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/4562aa55_9a5779ff
PS2, Line 275: `N``
> ``` […]
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/bb215fba_824b5028
PS2, Line 283: . Read `buff->data_len` samples, reset the buffer data (`data_len=0``),
: increment `next_read` and if read samples is `<N``, continue with next buffer
: until `next_read==next_write``, then block again or if timeout elapsed, then we
: reach conditon buffer underflow and `return len < N``.
> ``` […]
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/65a6b0ab_d519c183
PS2, Line 290: `N``
> ``` […]
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/89c3ddc6_57c5798d
PS2, Line 300: next_write was == next_read
> is this written as intended, maybe "next_write prev" would be more clear?
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/c1e5c28b_c38e8858
PS2, Line 294: . Write samples to `buff = stream->buffers[next_write]`. If `data_len!=0``,
: signal `buffer_overflow`` (increase field in stream object) and probably
: increase next_read``.
:
: . Increase `next_write``.
:
: . If `next_write was == next_read``, signal the reader through the other
: semaphore that it can continue reading.
> ``` […]
Done
File doc/manuals/chapters/trx-backends.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/9edef49b_b30e69e2
PS2, Line 132: * Test and experiment with _osmo-trx-ipc_.
: * Write your own IPC _Driver_ connecting to osmo-trx-ipc.
> these do not show up as bullet points in the pdf
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 27 Mar 2024 12:35:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: osmith <osmith(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: dexter, laforge, neels.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email )
Change subject: Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io
......................................................................
Patch Set 4:
(6 comments)
File src/libosmo-mgcp/mgcp_network.c:
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/afaf69e5_1474aeb2
PS4, Line 797: void forward_data_tap(struct osmo_io_fd *iofd, struct mgcp_rtp_tap *tap, struct msgb *msg)
we can probably constify "msg" in a followup patch here, it would help understand it's being copied and not owned by the function.
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/506d7a95_53ade661
PS4, Line 1047: * \param[in] msg message buffer that holds the data to be send.
Please document here:
""""
* If the function returns success (0), it will take ownership of the msgb and
* internally call msgb_free() after the sendto request completes.
* In case of an error the msgb needs to be freed by the caller.
""""
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/e7790112_b6d99ca9
PS4, Line 1520: .from_addr = (struct osmo_sockaddr *) saddr,
I odn't see why the cast is needed here? saddr is already that type.
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/e203edfd_d8e4c80b
PS4, Line 1696: if ((end->rtp && osmo_iofd_get_fd(end->rtp) != -1) ||
You can probably skip the "osmo_iofd_get_fd(end->rtp) != -1" check here, or otherwise make sure you free end->rtp before reassigning it below.
Same for RTCP.
I don't expect this to be a problem when running, but from a casual reader may look suspicious otherwise.
File src/libosmo-mgcp/mgcp_osmux.c:
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/e4d9cea0_8228b325
PS4, Line 526: goto out_free_v4;
you may be missing an "osmo_iofd_unregister()" in the section you are going with goto here. Or does osmo_iofd_free() include some sort of unregistering?
You are also probably missing close() of ipv4 fd?
File tests/mgcp/mgcp_test.c:
https://gerrit.osmocom.org/c/osmo-mgw/+/36363/comment/915e2d65_cccb2977
PS4, Line 661: uint8_t *buf = msgb_data(msg);
const
--
To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
Gerrit-Change-Number: 36363
Gerrit-PatchSet: 4
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 27 Mar 2024 12:27:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: fixeria.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36472?usp=email )
Change subject: msc: use as_expect_clear() in f_tc_mt_t310()
......................................................................
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36472?usp=email
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: I8185153502d31163fcb4c718690ee0f1cc912f5b
Gerrit-Change-Number: 36472
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 27 Mar 2024 10:00:44 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36470?usp=email )
Change subject: msc: fix f_tc_mt_crcx_ran_reject(): properly handle Iu-ReleaseCommand
......................................................................
Set Ready For Review
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36470?usp=email
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: Idd679bbf720a56a76cf37ab414b1e6d90e53278b
Gerrit-Change-Number: 36470
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Comment-Date: Wed, 27 Mar 2024 09:56:00 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: fixeria.
Hello Jenkins Builder, laforge,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36468?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Verified+1 by Jenkins Builder
The change is no longer submittable: Verified is unsatisfied now.
Change subject: msc: cosmetic: fix formatting in altsteps
......................................................................
msc: cosmetic: fix formatting in altsteps
Change-Id: I14afa9aa076396d48043000e350885384bde4c81
---
M msc/MSC_Tests.ttcn
1 file changed, 27 insertions(+), 18 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/68/36468/2
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36468?usp=email
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: I14afa9aa076396d48043000e350885384bde4c81
Gerrit-Change-Number: 36468
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newpatchset
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36472?usp=email )
Change subject: msc: use as_expect_clear() in f_tc_mt_t310()
......................................................................
msc: use as_expect_clear() in f_tc_mt_t310()
This testcase is not Iu-compatible yet, but let's make life a bit
easier for those trying to make it such in the future.
Change-Id: I8185153502d31163fcb4c718690ee0f1cc912f5b
---
M msc/MSC_Tests.ttcn
1 file changed, 13 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/72/36472/1
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index 101d632..52a5c2f 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -1850,7 +1850,7 @@
// FIXME: f_create_mgcp_delete_ep(cpars.mgcp_ep);
repeat;
}
- [] as_clear_cmd_compl_disc();
+ [] as_expect_clear() { setverdict(pass); }
}
}
testcase TC_mt_t310() runs on MTC_CT {
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36472?usp=email
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: I8185153502d31163fcb4c718690ee0f1cc912f5b
Gerrit-Change-Number: 36472
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: Hoernchen, laforge, pespin.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email )
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
Patch Set 2:
(1 comment)
File doc/manuals/chapters/ipc_if.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/308fd2b6_de81aac9
PS2, Line 42: Once connected, _osmo-trx-ipc_ will submit a `GREETING_REQ` message primitive
(The whole description of the IPC messages could be done with mscgen and diag graphs, like we do in e.g. the GSUP manuals: https://gitea.osmocom.org/cellular-infrastructure/osmo-gsm-manuals/src/bran… - IMHO this would make them more similar to other spec files we work with and easier to read... but doing this here would probably be a lot of effort, so feel free to ignore.)
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 27 Mar 2024 09:52:25 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36470?usp=email )
Change subject: msc: fix as_clear_cmd_compl_disc(): make it Iu-compatible
......................................................................
msc: fix as_clear_cmd_compl_disc(): make it Iu-compatible
Previous commit [1] uncovers a problem in as_clear_cmd_compl_disc():
this altstep is expecting BSSMAP Clear Command, which is specific
to the A-interface (GERAN). In TC_iu_mt_crcx_ran_reject though,
we receive RANAP Iu-ReleaseCommand, which is specific to the Iu-
interface (UTRAN), but not handled in this altstep.
The testcase was passing so far due to a bug in as_optional_cc_rel(),
which would unblock the alt-statemtnt on receipt of CC RELEASE, so
that we would never respond to RANAP Iu-ReleaseCommand.
Modify it to handle RANAP Iu-ReleaseCommand in addition to the
BSSMAP Clear Command. Take a change to remove the np-op argument.
Change-Id: Idd679bbf720a56a76cf37ab414b1e6d90e53278b
Related: [1] I0143b4d33b1ebe4cce99c09018540524c4626eec
---
M msc/BSC_ConnectionHandler.ttcn
1 file changed, 32 insertions(+), 10 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/70/36470/1
diff --git a/msc/BSC_ConnectionHandler.ttcn b/msc/BSC_ConnectionHandler.ttcn
index b3d915c..d10e2af 100644
--- a/msc/BSC_ConnectionHandler.ttcn
+++ b/msc/BSC_ConnectionHandler.ttcn
@@ -1967,19 +1967,18 @@
}
/* expect a clear command */
-altstep as_clear_cmd_compl_disc(float t := 5.0) runs on BSC_ConnHdlr {
+altstep as_clear_cmd_compl_disc() runs on BSC_ConnHdlr {
var PDU_BSSAP bssap;
- [] BSSAP.receive(tr_BSSMAP_ClearCommand) {
+
+ [g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_ClearCommand) {
BSSAP.send(ts_BSSMAP_ClearComplete);
- alt {
- [] BSSAP.receive(RAN_Conn_Prim:MSC_CONN_PRIM_DISC_IND) {
- setverdict(pass);
- }
- [] BSSAP.receive {
- setverdict(fail, "Unexpected BSSMAP while waiting for SCCP Release");
- mtc.stop;
- }
+ BSSAP.receive(RAN_Conn_Prim:MSC_CONN_PRIM_DISC_IND);
+ setverdict(pass);
}
+ [not g_pars.ran_is_geran] BSSAP.receive(tr_RANAP_IuReleaseCommand(?)) {
+ BSSAP.send(ts_RANAP_IuReleaseComplete);
+ BSSAP.receive(RAN_Conn_Prim:MSC_CONN_PRIM_DISC_IND);
+ setverdict(pass);
}
[] BSSAP.receive(tr_BSSAP_BSSMAP) -> value bssap {
setverdict(fail, "Unexpected BSSMAP while waiting for ClearCommand", bssap);
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36470?usp=email
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: Idd679bbf720a56a76cf37ab414b1e6d90e53278b
Gerrit-Change-Number: 36470
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newchange
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36469?usp=email )
Change subject: msc: fix missing 'repeat' in as_optional_cc_rel()
......................................................................
msc: fix missing 'repeat' in as_optional_cc_rel()
We do activate() this altstep in several testcases, so that it's
kinda "running in background". In reality, the defaults in TTCN-3
are just a syntax suggar, and the following code:
```
var default foo := activate(as_foo_bar());
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
}
PORT2.receive(tr_Msg3);
```
actually evaluates to:
```
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
[] as_foo_bar();
}
alt {
[] PORT2.receive(tr_Msg3);
[] as_foo_bar();
}
```
If as_foo_bar() contains no 'repeat' statement, then whenever it
triggers it would efficiently cancel (unblock) the current alt
statement, resulting in weird behavior due to messages not being
dequeued from ports as expected. And this is exactly what we
saw happening in OS#6414.
Change-Id: I0143b4d33b1ebe4cce99c09018540524c4626eec
Related: OS#6414
---
M msc/MSC_Tests.ttcn
1 file changed, 45 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/69/36469/1
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index 2b5af7c..7e8f467 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -187,6 +187,7 @@
}
BSSAP.send(ts_PDU_DTAP_MO(ts_ML3_MO_CC_REL_COMPL(cpars.transaction_id, tid_remote)));
}
+ repeat;
}
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36469?usp=email
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: I0143b4d33b1ebe4cce99c09018540524c4626eec
Gerrit-Change-Number: 36469
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newchange
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36467?usp=email )
Change subject: msc: fix f_tc_ho_inter_bsc0(): properly patch n_sd
......................................................................
msc: fix f_tc_ho_inter_bsc0(): properly patch n_sd
Assuming n_sd should be 3 is only valid for non-A5 testcases, in which
we are *not* doing ciphering and authentication. For the A5 testcases
(TC_ho_inter_bsc_a5_*), this assumption is incorrect and osmo-msc is
definitely not happy about that:
Duplicate DTAP: bin=0, expected n_sd == 0, got 3 (ran_msg.c:159)
Dropping duplicate message ... (msc_a.c:1363)
Why and how the A5 testcases passed so far? It was a pure luck, which
sailed away when we started executing ttcn3-msc-test with io_uring.
The A5 testcases were passing thanks to the as_optional_cc_rel() that
gets activate()d in background before calling f_call_hangup(). This
altstep does not have the 'repeat' statement, and as a side effect it
may cancel any normal alt-statements and even standalone receive()
statements.
In the successful scenario, it would cancel (unblock) the following
receive operation in f_call_hangup():
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
// ^^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
which is a pure luck because our CC RELEASE was sent with incorrect
sequence number and got dropped, so osmo-msc would never send us
CC RELEASE COMPLETE. It would instead send us CC RELEASE due to
expire of T306, and the as_optional_cc_rel() would kick in handling
this message and responding with CC RELEASE COMPLETE.
In the failing scenario though (when running with io_uring), that
same altstep running in backround may trigger *earlier* and unblock
another standalone receive() statement:
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
// ^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
so that we will be stuck waiting for CC RELEASE COMPLETE until the
Tguard expires.
This patch fixes n_sd patching, so that our CC RELEASE message is
handled properly and the call gets released as expected, without
requiring as_optional_cc_rel() to kick in. The missing 'repeat'
is to be added to as_optional_cc_rel() in a follow-up patch.
Change-Id: Iddde391eade716ca5c6c48cb631450ddb543e0d4
Related: OS#6414
---
M msc/MSC_Tests.ttcn
1 file changed, 65 insertions(+), 5 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/67/36467/1
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index 9db18d3..f99f93c 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -5778,6 +5778,10 @@
f_perform_lu();
f_mo_call_establish(cpars);
+ /* Remember the last n_sd (sequence number),
+ * we will need it when the other BSS hands over back to us. */
+ var N_Sd_Array last_n_sd := f_bssmap_last_n_sd();
+
f_sleep(1.0);
var default ack_mdcx := activate(as_mgcp_ack_all_mdcx(cpars));
@@ -5854,13 +5858,11 @@
deactivate(ack_mdcx);
- var default ccrel := activate(as_optional_cc_rel(cpars, true));
-
- /* blatant cheating */
- var N_Sd_Array last_n_sd := f_bssmap_last_n_sd();
- last_n_sd[0] := 3;
+ /* Use the n_sd (sequence number) we stored before the first handover.
+ * Otherwise the MSC may treat our DTAP messages as duplicates and discard them. */
f_bssmap_continue_after_n_sd(last_n_sd);
+ var default ccrel := activate(as_optional_cc_rel(cpars, true));
f_call_hangup(cpars, true);
f_sleep(1.0);
deactivate(ccrel);
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36467?usp=email
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: Iddde391eade716ca5c6c48cb631450ddb543e0d4
Gerrit-Change-Number: 36467
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newchange
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466?usp=email )
Change subject: fix MGCP_Test.TC_one_crcx_loopback_rtp_implicit expectations
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
Note that this patch as it is will, accurately, cause the 'latest' run of MGCP_Test.TC_one_crcx_loopback_rtp_implicit to fail.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466?usp=email
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: Ibe2ee59d1ed2c25ffef7e8534c172ac190b4983d
Gerrit-Change-Number: 36466
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Comment-Date: Wed, 27 Mar 2024 01:02:54 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466?usp=email )
Change subject: fix MGCP_Test.TC_one_crcx_loopback_rtp_implicit expectations
......................................................................
fix MGCP_Test.TC_one_crcx_loopback_rtp_implicit expectations
osmo-mgw should not respond to unknown peers. The test expected the
wrong thing, because of an old hack for 3G voice. Fix that.
Related: OS#6424
Change-Id: Ibe2ee59d1ed2c25ffef7e8534c172ac190b4983d
---
M mgw/MGCP_Test.ttcn
1 file changed, 29 insertions(+), 5 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/66/36466/1
diff --git a/mgw/MGCP_Test.ttcn b/mgw/MGCP_Test.ttcn
index 3161079..7090b34 100644
--- a/mgw/MGCP_Test.ttcn
+++ b/mgw/MGCP_Test.ttcn
@@ -1931,11 +1931,22 @@
stats := f_rtpem_stats_get(RTPEM[0]);
- if (stats.num_pkts_tx != stats.num_pkts_rx) {
- setverdict(fail);
- }
- if (stats.bytes_payload_tx != stats.bytes_payload_rx) {
- setverdict(fail);
+ if (one_phase) {
+ /* osmo-mgw knows both local and remote RTP address. Expect all packets to be reflected. */
+ if (stats.num_pkts_tx != stats.num_pkts_rx) {
+ setverdict(fail);
+ }
+ if (stats.bytes_payload_tx != stats.bytes_payload_rx) {
+ setverdict(fail);
+ }
+ } else {
+ /* osmo-mgw knows only the local RTP address. Expect no packets to be reflected. */
+ if (stats.num_pkts_rx > 0) {
+ setverdict(fail, "stats.num_pkts_rx=", stats.num_pkts_rx, ": osmo-mgw should not send RTP packets to an arbitrary peer");
+ }
+ if (stats.bytes_payload_rx > 0) {
+ setverdict(fail);
+ }
}
f_rtpem_stats_err_check(stats);
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466?usp=email
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: Ibe2ee59d1ed2c25ffef7e8534c172ac190b4983d
Gerrit-Change-Number: 36466
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: Hoernchen, fixeria, laforge, osmith.
Hello Hoernchen, Jenkins Builder, fixeria, laforge, osmith,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Code-Review+1 by fixeria, Code-Review+1 by laforge, Verified+1 by Jenkins Builder
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
doc: Introduce documentation for osmo-trx-ipc and its IPC interface
Related: SYS#6861
Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
---
M doc/manuals/chapters/code-architecture.adoc
A doc/manuals/chapters/ipc_if.adoc
M doc/manuals/chapters/trx-backends.adoc
M doc/manuals/osmotrx-usermanual.adoc
4 files changed, 413 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-trx refs/changes/65/36465/2
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: Hoernchen, fixeria, osmith.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email )
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
Patch Set 1:
(4 comments)
File doc/manuals/chapters/ipc_if.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/ee2d1a91_f8030a4a
PS1, Line 16: different
> "various"?
Done
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/8bd181d0_63014053
PS1, Line 28: * _Channel_ UD socket: One for
: each channel man
> is this going to be rendered as a single line?
Yes, but I fixed it anyway.
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/45c4b313_8d16833a
PS1, Line 94: `!0` on error
> `!= 0`?
To me "!0" is more easily readable here, since it's not really a comparison operator, just negating it.
File doc/manuals/chapters/trx-backends.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/602bd805_a8ace44a
PS1, Line 126: and also
> line break
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 20:34:45 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: Hoernchen, osmith, pespin.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email )
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
Patch Set 1: Code-Review+1
(4 comments)
File doc/manuals/chapters/ipc_if.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/9ae8b421_09830b67
PS1, Line 16: different
"various"?
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/765a48cc_b98981cb
PS1, Line 28: * _Channel_ UD socket: One for
: each channel man
is this going to be rendered as a single line?
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/bcefcc65_e2a089e9
PS1, Line 94: `!0` on error
`!= 0`?
File doc/manuals/chapters/trx-backends.adoc:
https://gerrit.osmocom.org/c/osmo-trx/+/36465/comment/aefb6b37_ae980b65
PS1, Line 126: and also
line break
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 18:45:12 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: dexter, laforge, neels, pespin.
Hello Jenkins Builder, dexter, neels, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email
to look at the new patch set (#4).
The following approvals got outdated and were removed:
Verified-1 by Jenkins Builder
Change subject: Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io
......................................................................
Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io
Converting from osmo_fd to osmo_io allows us to switch to the new
io_uring backend and benefit from related performance benefits.
In a benchmark running 200 concurrent bi-directional voice calls with
GSM-EFR codec, I am observing:
* the code before this patch uses 40..42% of a single core on a
Ryzen 5950X at 200 calls (=> 200 endpoints with each two connections)
* no increase in CPU utilization before/after this patch, i.e. the
osmo_io overhead for the osmo_fd backend is insignificant compared
to the direct osmo_fd mode before
* an almost exactly 50% reduction of CPU utilization when running the
same osmo-mgw build with LIBOSMO_IO_BACKEND=IO_URING - top shows
19..21% for the same workload instead of 40..42% with the OSMO_FD
default backend.
* An increase of about 4 Megabytes in both RSS and VIRT size when
enabling the OSMO_IO backend. This is likely the memory-mapped rings.
No memory leakage is observed when using either of the backends.
Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
---
M include/osmocom/mgcp/mgcp.h
M include/osmocom/mgcp/mgcp_network.h
M src/libosmo-mgcp/mgcp_conn.c
M src/libosmo-mgcp/mgcp_iuup.c
M src/libosmo-mgcp/mgcp_network.c
M src/libosmo-mgcp/mgcp_osmux.c
M tests/mgcp/mgcp_test.c
7 files changed, 232 insertions(+), 169 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/63/36363/4
--
To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
Gerrit-Change-Number: 36363
Gerrit-PatchSet: 4
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newpatchset
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36463?usp=email )
Change subject: [cosmetic] mgw: fix spelling in comments
......................................................................
[cosmetic] mgw: fix spelling in comments
Change-Id: I2fb69463b070cdc183fff63ee7dc422169f8928a
---
M mgw/MGCP_Test.ttcn
1 file changed, 12 insertions(+), 3 deletions(-)
Approvals:
Jenkins Builder: Verified
pespin: Looks good to me, approved
diff --git a/mgw/MGCP_Test.ttcn b/mgw/MGCP_Test.ttcn
index b7d6b46..3161079 100644
--- a/mgw/MGCP_Test.ttcn
+++ b/mgw/MGCP_Test.ttcn
@@ -2703,7 +2703,7 @@
mgcp_transceive_mgw(cmd, tr_CRCX_ACK);
}
- /* Wait until the stats items have seteled and then check if we get the expected number (all) of
+ /* Wait until the stats items have settled and then check if we get the expected number (all) of
* occupied endpoints */
f_sleep(1.0)
expect := {
@@ -2724,14 +2724,14 @@
cmd := ts_DLCX(get_next_trans_id(), ep);
mgcp_transceive_mgw(cmd, rtmpl);
- /* Query a the statsd once to ensure that intermediate results are pulled from the
+ /* Query the statsd once to ensure that intermediate results are pulled from the
* pipeline. The second query (below) will return the actual result. */
expect := {
{ name := "TTCN3.trunk.e1-1.common.endpoints.used", mtype := "g", min := 0, max := n_e1_ts * 4}
};
f_statsd_expect(expect);
- /* The second query must resturn a result with 0 endpoints in use. */
+ /* The second query must return a result with 0 endpoints in use. */
expect := {
{ name := "TTCN3.trunk.e1-1.common.endpoints.used", mtype := "g", min := 0, max := 0}
};
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36463?usp=email
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: I2fb69463b070cdc183fff63ee7dc422169f8928a
Gerrit-Change-Number: 36463
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36461?usp=email )
Change subject: ggsn: Avoid dynamic test case error
......................................................................
ggsn: Avoid dynamic test case error
During TC_addr_pool_exhaustion, if all of the pdp context activations
were unsuccessful, teic_list is an empty list. We therefore cannot
unconditionally obtain its first element.
This patch avoids the related "Index overflow in a value of type
@PreGenRecordOf.PREGEN_RECORD_OF_OCTETSTRING: The index is 0, but the
value has only 0 elements."
Related: OS#6423
Change-Id: I7c7a84ed8343fb48e841248f86d37972f4674ed0
---
M ggsn_tests/GGSN_Tests.ttcn
1 file changed, 19 insertions(+), 1 deletion(-)
Approvals:
osmith: Looks good to me, but someone else must approve
Jenkins Builder: Verified
pespin: Looks good to me, approved
diff --git a/ggsn_tests/GGSN_Tests.ttcn b/ggsn_tests/GGSN_Tests.ttcn
index e2d5fb2..8672947 100644
--- a/ggsn_tests/GGSN_Tests.ttcn
+++ b/ggsn_tests/GGSN_Tests.ttcn
@@ -2080,7 +2080,7 @@
[Gx_PROC.checkstate("Connected")] as_DIA_Gx_CCR(TERMINATION_REQUEST) { repeat; }
[Gy_PROC.checkstate("Connected")] as_DIA_Gy_CCR(omit, TERMINATION_REQUEST) { repeat; }
[] pingpong();
- [] T_next.timeout {
+ [lengthof(teic_list) > 0] T_next.timeout {
f_send_gtpc(ts_GTPC_DeletePDP(g_peer_c, g_c_seq_nr, teic_list[next_req_ctx], '0001'B, '1'B));
next_req_ctx := next_req_ctx + 1;
if (next_req_ctx < num_ctx) {
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36461?usp=email
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: I7c7a84ed8343fb48e841248f86d37972f4674ed0
Gerrit-Change-Number: 36461
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email )
Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface
......................................................................
doc: Introduce documentation for osmo-trx-ipc and its IPC interface
Related: SYS#6861
Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
---
M doc/manuals/chapters/code-architecture.adoc
A doc/manuals/chapters/ipc_if.adoc
M doc/manuals/chapters/trx-backends.adoc
M doc/manuals/osmotrx-usermanual.adoc
4 files changed, 411 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-trx refs/changes/65/36465/1
diff --git a/doc/manuals/chapters/code-architecture.adoc b/doc/manuals/chapters/code-architecture.adoc
index 1cb2542..5311dbe 100644
--- a/doc/manuals/chapters/code-architecture.adoc
+++ b/doc/manuals/chapters/code-architecture.adoc
@@ -17,6 +17,7 @@
7[label = "{UHDDevice|...}"]
8[label = "{LMSDevice|...}"]
9[label = "{USRPDevice|...}"]
+10[label = "{IPCDevice|...}"]
2->3[arrowtail=odiamond]
3->4[constraint=false]
@@ -25,6 +26,7 @@
6->7
6->8
6->9
+6->10
}
----
diff --git a/doc/manuals/chapters/ipc_if.adoc b/doc/manuals/chapters/ipc_if.adoc
new file mode 100644
index 0000000..1e1f2bd
--- /dev/null
+++ b/doc/manuals/chapters/ipc_if.adoc
@@ -0,0 +1,302 @@
+[[ipc_if]]
+== osmo-trx-ipc IPC Interface
+
+This interface is the one used by _osmo_trx_ipc_ backend to communicate to a
+third party process in charge of driving the lowest layer device-specific bits
+(from now on the Driver).
+
+It consists of a set of Unix Domain (UD) sockets for the control plane, plus a
+shared memory region for the data plane.
+
+Related code can be found in the
+https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc[Transceiver52M/device/ipc/]
+directory in _osmo-trx.git_.
+
+If you are a potential driver implementator, the
+different primitives and data structures are publicly available in header file
+https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h].
+
+=== Control plane
+
+Control plane protocol is transmitted over Unix Domain (UD) sockets using
+message based primitives. Each primitive has a type identified by an integer,
+and each type of primitive has a number of extra attributes attached to it. The
+IPC interface consists of 2 types of UD sockets:
+
+* _Master_ UD socket: One per osmo-trx-ipc process.
+
+* _Channel_ UD socket: One for
+each channel managed by osmo-trx-ipc process.
+
+The _Driver_ is in all cases expected to take the server role when creating UD
+sockets, while _osmo-trx-ipc_ takes the client role and connects to sockets
+provided by the driver.
+
+=== Master UD socket
+
+During startup, _osmo-trx-ipc_ will try connecting to the _Driver_ Master UD
+socket located in the path provided by its own (VTY) configuration. As a result,
+it means the _Driver_ process must be running and listening on the Master UD
+socket before _osmo-trx-ipc_ is started, otherwise _osmo-trx-ipc_ will fail and
+exit.
+
+Once connected, _osmo-trx-ipc_ will submit a `GREETING_REQ` message primitive
+announcing the maximum supported protocol version (first version ever is `1`,
+increasing over time).
+
+The _Driver_ shall then answer in `GREETING_CNF` message primitive with its own
+maximum supported version (`<=` version received), providing 0 if none is
+supported.
+
+If _osmo-trx-ipc_ receives back the requested version, then both sides agreed
+on the protocol version to use.
+If _osmo-trx-ipc_ receives back a lower version, it shall decide to continue
+with version negotiation using a lower version, until a supported version or 0
+is received. If finally 0 is received, _osmo-trx-ipc_ will disconnect and exit
+with failure.
+
+Once the version is negotiated (`v1` as of current date), _osmo-trx-ipc_ will
+ask for device information and available characeristics to the _Driver_ using
+the `INFO_REQ` message primitive.
+
+The _Driver_ shall then answer with a `INFO_CNF` message
+containing information, such as:
+
+* String containing device description
+
+* Available reference clocks,
+
+* {rx,tx} I/Q scaling factors
+
+* Maximum number of channels supported
+
+* for each channel:
+
+** List of available {rx,tx} paths/antennas.
+
+** {min,max}{rx,tx} gains
+
+** Nominal transmit power
+
+All the information received from the _Driver_ during `INFO_CNF` will be used by
+_osmo-trx-ipc_ to decide whether it can fullfil the requested configuration from
+the user, and proceed to open the device, or exit with a failure (for instance
+number of channels, referece clock or tx/rx antenna selected by the user cannot
+be fullfilled).
+
+_osmo-trx-ipc_ will then proceed to open the device and do an initial
+configuration using an `OPEN_REQ` message, where it will provide the _Driver_
+with the desired selected configuration (such as number of channels, rx/tx
+paths, clock reference, bandwidth filters, etc.).
+
+The _Driver_ shall then configure the device and send back a `OPEN_CNF` with:
+
+* `return_code` integer attribute set to `0` on success or `!0` on error.
+
+* Name of the Posix Shared Memory region where data plane is going to be
+transmitted.
+
+* One path for each channel, containing the just-created UD socket to manage
+that channel (for instance by taking Master UD socket path and appending
+`_$chan_idx`).
+
+* Path Delay: this is the loopback path delay in samples (= used as a timestamp
+offset internally by _osmo-trx-ipc_), this value contains the analog delay as
+well as the delay introduced by the digital filters in the fpga in the sdr
+devices, and is therefore device type and bandwidth/sample rate dependant. This
+can not be omitted, wrong values will lead to a _osmo-trx-ipc_ that just doesn't
+detect any bursts.
+
+Finally, _osmo-trx-ipc_ will connect to each channel's UD socket (see next
+section).
+
+Upon _osmo-trx-ipc_ closing the UD master socket connection, the _Driver_ shall
+go into @closed@ state: stop all processing and instruct the device to power
+off.
+
+TIP: See
+https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h]
+for the detailed definition of all the related message primitives and data
+types for this socket.
+
+=== Channel UD Socket
+
+This socket can be used by _osmo-trx-ipc_ to start/stop data plane processing or
+change channel's parameters such as Rx/Tx Frequency, Rx/Tx gains, etc.
+
+A channel can be either in _started_ or _stopped_ state. When a channel is
+created (during `OPEN_REQ` in the Master UD Socket), it's by default in
+_stopped_ state. `START_REQ` and `STOP_REQ` messages control this state, and
+eventual failures can be reported through `START_CNF` and `STOP_CNF` by the
+_Driver_.
+
+The message `START_REQ` instructs the _Driver_ to start processing data in the
+data plane. Similary, `STOP_REQ` instructs the _Driver_ to stop processing data
+in the data plane.
+
+Some parameters are usually changed only when the channel is in stopped mode,
+for instance Rx/Tx Frequency.
+
+TIP: See
+https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h]
+for the detailed definition of all the related message primitives and data
+types for this socket.
+
+=== Data Plane
+
+Data plane protocol is implemented by means of a ring buffer structure on top of
+Posix Shared Memory (see `man 7 shm_overview`) between _osmo-trx-ipc_ process
+and the _Driver_.
+
+The Posix Shared Memory region is created and its memory structure prepared by
+the _Driver_ and its name shared with _osmo-trx-ipc_ during _OPEN_CNF_ message
+in the Master UD Socket from the Control Plane. Resource allocation for the
+shared memory area and cleanup is up to the ipc server, as is mutex
+initialization for the buffers.
+
+==== Posix Shared Memory structure
+
+[[fig-shm-structure]]
+.General overview of Posix Shared Memory structure
+[graphviz]
+----
+digraph hierarchy {
+node[shape=record,style=filled,fillcolor=gray95]
+edge[dir=back, arrowtail=empty]
+
+SHM[label = "{Posix Shared Memory region|+ num_chans\l+ Channels[]\l}"]
+CHAN0[label = "{Channel 0|...}"]
+CHAN1[label = "{Channel 1|...}"]
+CHANN[label = "{Channel ...|}"]
+STREAM0_UL[label = "{UL Stream|+ semaphore\l+ read_next\l+write_next\l+ buffer_size /* In samples */\l+ num_buffers\l+ sample_buffers[]\l}"]
+STREAM0_DL[label = "{DL Stream|+ semaphore\l+ read_next\l+write_next\l+ buffer_size /* In samples */\l+ num_buffers\l+ sample_buffers[]\l}"]
+STREAM1_UL[label = "{UL Stream|...}"]
+STREAM1_DL[label = "{DL Stream|...}"]
+STREAMN_UL[label = "{UL Stream|...}"]
+STREAMN_DL[label = "{DL Stream|...}"]
+BUF_0DL0[label = "{DL Sample Buffer 0|+ timestamp\l+ buffer_size /* In samples */\l+ samples[] = [16bit I + 16bit Q,...]\l}"]
+BUF_0DLN[label = "{DL Sample Buffer ....|...}"]
+BUF_0UL0[label = "{UL Sample Buffer 0|+ timestamp\l+ buffer_size /* In samples */\l+ samples[] = [16bit I + 16bit Q,...]\l}"]
+BUF_0ULN[label = "{UL Sample Buffer ...|...}"]
+
+SHM->CHAN0
+SHM->CHAN1
+SHM->CHANN
+
+CHAN0->STREAM0_DL
+CHAN0->STREAM0_UL
+STREAM0_DL->BUF_0DL0
+STREAM0_DL->BUF_0DLN
+STREAM0_UL->BUF_0UL0
+STREAM0_UL->BUF_0ULN
+
+CHAN1->STREAM1_UL
+CHAN1->STREAM1_DL
+
+CHANN->STREAMN_UL
+CHANN->STREAMN_DL
+}
+----
+
+The Posix Shared Memory region contains an array of _Channels_.
+
+Each _Channel_ contains 2 Streams:
+
+* Downlink _Stream_
+
+* Uplink _Stream_
+
+Each _Stream_ handles a ring buffer, which is implemented as:
+
+* An array of pointers to _Sample Buffer_ structures.
+
+* Variables containing the number of buffers in the array, as well as the
+maximum size in samples for each Sample Buffer.
+
+* Variables containing `next_read` and `next_write` _Sample Buffer_ (its index
+in the array of pointers).
+
+* Unnamed Posix semaphores to do the required locking while using the ring
+buffer.
+
+Each _Sample Buffer_ contains:
+
+* A `timestamp`` variable, containing the position in the stream of the first
+sample in the buffer
+
+* A `data_len`` variable, containing the amount of samples available to process
+in the buffer
+
+* An array of samples of size specified by the stream struct it is part of.
+
+==== Posix Shared Memory format
+
+The Posix Shared memory region shall be formatted applying the following
+considerations:
+
+* All pointers in the memory region are encoded as offsets from the start
+address of the region itself, to allow different processes with different
+address spaces to decode them.
+
+* All structs must be force-aligned to 8 bytes
+
+* Number of buffers must be power of 2 (2,4,8,16,...) - 4 appears to be plenty
+
+* IQ samples format: One (complex) sample consists of 16bit i + 16bit q, so the
+buffer size is number of IQ pairs.
+
+* A reasonable per-buffer size (in samples) is 2500, since this happens to be
+the ususal TX (downlink) buffer size used by _osmo-trx-ipc_ with the b210 (rx
+over-the-wire packet size for the b210 is 2040 samples, so the larger value of
+both is convenient).
+
+TIP: See
+https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h]
+for the detailed definition of all the objects being part of the Posix Shared
+memory region structure
+
+==== Posix Shared Memory procedures
+
+The queue in the shared memory area is not supposed to be used for actual
+buffering of data, only for exchange, so the general expectation is that it is
+mostly empty. The only exception to that might be minor processing delays, and
+during startup.
+
+Care must be taken to ensure that only timed waits for the mutex protecting it
+and the condition variables are used, in order to ensure that no deadlock occurs
+should the other side die/quit.
+
+Thread cancellation should be disabled during reads/writes from/to the queue. In
+general a timeout can be considered a non recoverable error during regular
+processing after startup, at least with the current timeout value of one second.
+
+Should over- or underflows occur a corresponding message should be sent towards
+_osmo-trx-ipc_.
+
+Upon **read** of `N`` samples, the reader does something like:
+
+. Acquire the semaphore in the channel's stream object.
+
+. Read `stream->next_read`, if `next_read==next_write`, become blocked in
+another sempahore (unlocking the previous one) until writer signals us, then
+`buff = stream->buffers[next_read]`
+
+. Read `buff->data_len` samples, reset the buffer data (`data_len=0``),
+increment `next_read` and if read samples is `<N``, continue with next buffer
+until `next_read==next_write``, then block again or if timeout elapsed, then we
+reach conditon buffer underflow and `return len < N``.
+
+. Release the semaphore
+
+Upon **write** of `N`` samples, the writer does something like:
+
+. Acquire the semapore in the channel's stream object.
+
+. Write samples to `buff = stream->buffers[next_write]`. If `data_len!=0``,
+signal `buffer_overflow`` (increase field in stream object) and probably
+increase next_read``.
+
+. Increase `next_write``.
+
+. If `next_write was == next_read``, signal the reader through the other
+semaphore that it can continue reading.
\ No newline at end of file
diff --git a/doc/manuals/chapters/trx-backends.adoc b/doc/manuals/chapters/trx-backends.adoc
index 78bc45d..e5cacec 100644
--- a/doc/manuals/chapters/trx-backends.adoc
+++ b/doc/manuals/chapters/trx-backends.adoc
@@ -71,3 +71,98 @@
in a buffer, and read commands to the USRP simply pull data from this buffer.
This was very useful in early testing, and still may be useful in testing basic
Transceiver and radioInterface functionality.
+
+
+[[backend_ipc]]
+=== `osmo-trx-ipc` Inter Process Communication backend
+
+This OsmoTRX model provides its own Inter Process Communication (IPC) interface
+to drive the radio device driver (from now on the Driver), allowing for third
+party processes to implement the lowest layer device-specific bits without being
+affected by copyleft licenses of OsmoTRX.
+
+For more information on such interface, see section <<ipc_if>>.
+
+[[fig-backend-ipc]]
+.Architecture with _osmo-trx-ipc_ and its IPC _Driver_
+[graphviz]
+----
+digraph G {
+ rankdir=LR;
+ MS0 [label="MS"];
+ MS1 [label="MS"];
+ OsmoTRX [label="osmo-trx-ipc", color=red];
+ BTS;
+
+ subgraph cluster_ipc_driver {
+ label = "IPC Driver";
+ color=red;
+ RE [label = "Radio Equipment"];
+ REC [label="Radio Equipment Controller"];
+ RE->REC;
+ }
+
+ REC->OsmoTRX [label="IPC Interface", color=red];
+
+ MS0->RE [label="Um"];
+ MS1->RE [label="Um"];
+ OsmoTRX->BTS [label="bursts over UDP"];
+
+}
+----
+
+A sample config file for this OsmoTRX model can be found in _osmo-trx.git_ https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste…
+
+In the config file, the following VTY command can be used to set up the IPC UD Master Socket _osmo-trx-ipc_ will connect to at startup:
+
+.Example: _osmo-trx-ipc_ will connect to UD Master Socket /tmp/ipc_sock0 upon startup
+----
+dev-args ipc_msock=/tmp/ipc_sock0
+----
+
+==== ipc-device-test
+
+When built with `--with-ipc --with-uhd` configure options, _osmo-trx.git_ will build the test program called _ipc-driver-test_.
+This program implements the _Driver_ side of the osmo-trx-ipc interface (see <<ipc_if>> for more information) on one side, and also interacts internally with UHD (eg B210 as when using osmo-trx-uhd).
+
+You can use this small program as a reference to:
+* Test and experiment with _osmo-trx-ipc_.
+* Write your own IPC _Driver_ connecting to osmo-trx-ipc.
+
+[[fig-backend-ipc-device-test]]
+.Architecture with _osmo-trx-ipc_ and ipc-device-test as IPC _Driver_
+[graphviz]
+----
+digraph G {
+ rankdir=LR;
+ MS0 [label="MS"];
+ MS1 [label="MS"];
+ SDR;
+ ipc_device_test[label = "ipc-device-test", color=red];
+ OsmoTRX [label="osmo-trx-ipc", color=red];
+ BTS;
+
+ MS0->SDR [label="Um"];
+ MS1->SDR [label="Um"];
+ SDR->ipc_device_test [label="UHD"];
+ ipc_device_test->OsmoTRX [label="IPC Interface", color=red];
+ OsmoTRX->BTS [label="bursts over UDP"];
+}
+----
+
+The code for this app is found here:
+
+* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste…
+
+* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste…
+
+Those files use the server-side (_Driver_ side) code to operate the Posix Shared
+Memory region implemented in files `shm.c`, `shm.h`, `ipc_shm.c` and `ipc_shm.h`
+in the same directory.
+
+Most of the code in that same directory is deliverately released under a BSD
+license (unlike most of _osmo-trx.git_), allowing third parties to reuse/recycle
+the code on their implemented _Driver_ program no matter it being proprietary or
+under an open license. However, care must be taken with external dependencies,
+as for instance shm.c uses the talloc memory allocator, which is GPL licensed
+and hence cannot be used in a proprietary driver.
\ No newline at end of file
diff --git a/doc/manuals/osmotrx-usermanual.adoc b/doc/manuals/osmotrx-usermanual.adoc
index 2d1caad..b768306 100644
--- a/doc/manuals/osmotrx-usermanual.adoc
+++ b/doc/manuals/osmotrx-usermanual.adoc
@@ -35,6 +35,8 @@
include::./common/chapters/trx_if.adoc[]
+include::{srcdir}/chapters/ipc_if.adoc[]
+
include::./common/chapters/port_numbers.adoc[]
include::./common/chapters/bibliography.adoc[]
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed
Gerrit-Change-Number: 36465
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
fixeria has submitted this change. ( https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email )
Change subject: ttcn3-bts-test: fix start_config_oml(): do not start BSC
......................................................................
ttcn3-bts-test: fix start_config_oml(): do not start BSC
As the comment states, the BSC container is not needed for the OML
tests. The testsuite itself "speaks" OML to the IUT in this case.
Change-Id: Iab44b9ed83e917475c9e2e86ad32b303b05b2ace
Fixes: aad045f5 "ttcn3-bts-test: add env var to not run all configs"
Fixes: OS#6421
---
M ttcn3-bts-test/jenkins.sh
1 file changed, 14 insertions(+), 2 deletions(-)
Approvals:
Jenkins Builder: Verified
pespin: Looks good to me, approved
laforge: Looks good to me, but someone else must approve
diff --git a/ttcn3-bts-test/jenkins.sh b/ttcn3-bts-test/jenkins.sh
index ed4ae37..38e3760 100755
--- a/ttcn3-bts-test/jenkins.sh
+++ b/ttcn3-bts-test/jenkins.sh
@@ -187,7 +187,6 @@
cp oml/osmo-bts.gen.cfg $VOL_BASE_DIR/bts/
network_replace_subnet_in_configs
- start_bsc
start_bts trx 1
start_fake_trx
start_trxcon
@@ -197,7 +196,6 @@
docker_kill_wait ${BUILD_TAG}-trxcon
docker_kill_wait ${BUILD_TAG}-fake_trx
docker_kill_wait ${BUILD_TAG}-bts
- docker_kill_wait ${BUILD_TAG}-bsc
}
# Frequency hopping tests require different configuration files
--
To view, visit https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: docker-playground
Gerrit-Branch: master
Gerrit-Change-Id: Iab44b9ed83e917475c9e2e86ad32b303b05b2ace
Gerrit-Change-Number: 36462
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: fixeria, neels.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email )
Change subject: fix VLR evil twin on LU with unknown TMSI
......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-msc/+/36452/comment/d1718f8a_e55af610
PS1, Line 15: be discarded, for the benefit of the new one.
> interesting, which way around is that? do we also drop the old one there?
Yes, definetly drop the old one. In osmo-pcu is even more complex because we first lookup by TBF, and then the assigned MS object, but sometimes the MS object has non-yet-known-imsi. So at some point, when figuring out the IMSI, we figure out we have a duplicated MS object and we need to move gained information from the previous MS object and then drop that MS object plus its related TBFs.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
Gerrit-Change-Number: 36452
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
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-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 14:24:56 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: fixeria, neels.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455?usp=email )
Change subject: msc: f_expect_paging(): fix by_tmsi arg
......................................................................
Patch Set 1:
(1 comment)
File msc/BSC_ConnectionHandler.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455/comment/bba73e94_78e6…
PS1, Line 1360: boolean by_tmsi := true
> What I meant to say is: this function has a specific signature, and I want to avoid changing that an […]
I don't even know why I'm doing code review if 99% of what I say seems to be irrelevant, bikeshed, etc.
But then later on I find myself having to fix this kind of stuff when looking/modifying code.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455?usp=email
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: I9434745b7faeb738caafed8080b9f7b1a6a8079a
Gerrit-Change-Number: 36455
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 14:18:31 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: fixeria, neels.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36459?usp=email )
Change subject: msc: add TC_lu_tmsi_noauth_notmsi
......................................................................
Patch Set 1:
(1 comment)
File msc/MSC_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36459/comment/9d53f123_d148…
PS1, Line 7312: valueof
> would it not have to be a "template (value)" arg? So far it is "template (omit)", and I do still not […]
1- a "template (value)" parameter can be passed either a "template (value)" var or a value val, both are correct.
Because a value is a subset of "template (value)" let's say, in the sense that eg. "template (value)" is a subset of "template (omit)".
2- You may not care about ttcn3 "cosmetics", but I do because later on I see lots of warnings when compiling, which is annoying, and sometimes I need to rework tons of templates myself to pass proper stuff.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36459?usp=email
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: If10b9987395670b084ff8ad6d1f033ff46896d75
Gerrit-Change-Number: 36459
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 14:14:37 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: fixeria, laforge, pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email )
Change subject: fix VLR evil twin on LU with unknown TMSI
......................................................................
Patch Set 1:
(4 comments)
Commit Message:
https://gerrit.osmocom.org/c/osmo-msc/+/36452/comment/ee0aa82e_04e646a3
PS1, Line 15: be discarded, for the benefit of the new one.
> we do the same in osmo-pcu with tbfs btw (ms_merge_and_clear_ms()).
interesting, which way around is that? do we also drop the old one there?
Patchset:
PS1:
> are we sure this code path only gets triggered after authentication [assuming authentication is enab […]
I thought about that, too. The situation is:
This happens before Auth:
- the MSC gets a LU request by TMSI,
- then requires the IMSI
- the ID response for that triggers this de-duplication.
- authentication follows.
- we can copy auth tuples safely.
- i am not copying state like the security status or FSM states that might skip important validations.
- we always have to know a subscriber's IMSI, i.e. the code makes sure that an IMSI is known in order to contact the HLR. This triggers only in a situation where the IMSI is not yet known, i.e. only possible in the short phase before the ID Request, before auth. i.e. not possible to sneakily hijack another IMSI's security context.
If authentication is switched off, then this doesn't hold of course, but nothing else does either.
File src/libmsc/paging.c:
https://gerrit.osmocom.org/c/osmo-msc/+/36452/comment/7e963ad9_991297fe
PS1, Line 147: vlr_subscr_put(discarding_vsub, VSUB_USE_PAGING);
> Ah indeed it missed that one.
yes, i wanted to keep that close together, but the use count put should happen in the end, while the if() should happen in the start... i'll drop a comment there
File src/libvlr/vlr.c:
https://gerrit.osmocom.org/c/osmo-msc/+/36452/comment/e207ac85_0f270790
PS1, Line 597: struct vlr_instance *vlr = exists->vlr;
> I'd rpobably move all this code to its own function "vsub_join()" or alike.
ack
(the paging_request_join() function was supposed to be that own function, but then this code here grew and grew with more aspects to be taken care of...)
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
Gerrit-Change-Number: 36452
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 26 Mar 2024 14:13:59 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment