Attention is currently required from: laforge.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/30437 )
Change subject: gsmtap.h: Add definitions for various ISDN sub-types
......................................................................
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/30437
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I8dee0f730cf91d6f9133d5c57f653e669ec8d598
Gerrit-Change-Number: 30437
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Fri, 02 Dec 2022 17:55:28 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: Hoernchen, pespin.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/30414 )
Change subject: ill-fated ipcv2 for mstrx
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
ok, then lets push that into a branch and abandon this gerrit patch
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/30414
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: I8f582c7c06fed8d1dcc5ea52472a97dc313fdde5
Gerrit-Change-Number: 30414
Gerrit-PatchSet: 2
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 02 Dec 2022 16:29:00 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/pysim/+/30435 )
Change subject: sysmocom_sja2: simplify and fix op/opc decoder/encoder
......................................................................
sysmocom_sja2: simplify and fix op/opc decoder/encoder
The decoder/encoder of that decodes the EF.xSIM_AUTH_KEY files has an
overcomplicated handling for op/and opc. There is a condition that
checks if milenage is configured and another one that checks if the
string is recognized as OP or OPc. Both is not correct and seems not to
work (op and opc is always displayed as "null")
The encoder/decoder should focus on the physical file layout and
regardless of any other conriguration the OP/OPc field is physically
present and should be displayd and presented for editing.
Change-Id: I6fa3a07e5e473273498d3f13d4cfa33743b787e1
---
M pySim/sysmocom_sja2.py
1 file changed, 3 insertions(+), 20 deletions(-)
Approvals:
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/pySim/sysmocom_sja2.py b/pySim/sysmocom_sja2.py
index 53e6585..a78318e 100644
--- a/pySim/sysmocom_sja2.py
+++ b/pySim/sysmocom_sja2.py
@@ -143,12 +143,7 @@
'algorithm'/Enum(Nibble, milenage=4, comp128v1=1, comp128v2=2, comp128v3=3))
self._construct = Struct('cfg'/CfgByte,
'key'/HexAdapter(Bytes(16)),
- 'op'/ If(this.cfg.algorithm == 'milenage' and not this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16))),
- 'opc' /
- If(this.cfg.algorithm == 'milenage' and this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16)))
- )
+ 'op_opc' /HexAdapter(Bytes(16)))
class DF_SYSTEM(CardDF):
@@ -198,13 +193,7 @@
'algorithm'/Enum(Nibble, milenage=4, sha1_aka=5, xor=15))
self._construct = Struct('cfg'/CfgByte,
'key'/HexAdapter(Bytes(16)),
- 'op' /
- If(this.cfg.algorithm == 'milenage' and not this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16))),
- 'opc' /
- If(this.cfg.algorithm == 'milenage' and this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16)))
- )
+ 'op_opc' /HexAdapter(Bytes(16)))
class EF_USIM_AUTH_KEY_2G(TransparentEF):
@@ -216,13 +205,7 @@
'algorithm'/Enum(Nibble, milenage=4, comp128v1=1, comp128v2=2, comp128v3=3))
self._construct = Struct('cfg'/CfgByte,
'key'/HexAdapter(Bytes(16)),
- 'op' /
- If(this.cfg.algorithm == 'milenage' and not this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16))),
- 'opc' /
- If(this.cfg.algorithm == 'milenage' and this.cfg.use_opc_instead_of_op,
- HexAdapter(Bytes(16)))
- )
+ 'op_opc' /HexAdapter(Bytes(16)))
class EF_GBA_SK(TransparentEF):
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/30435
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I6fa3a07e5e473273498d3f13d4cfa33743b787e1
Gerrit-Change-Number: 30435
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30374 )
Change subject: pcu: TC_paging_cs_from_sgsn_*: Fix race condition between BSSGP tx and RLCMAC rx
......................................................................
pcu: TC_paging_cs_from_sgsn_*: Fix race condition between BSSGP tx and RLCMAC rx
It can happen that the RLCMAC req arrives at osmo-pcu before the
CS_PAGING we send to it over BSSGP, in which case osmo-pcu will schedule
an RLCMAC DL Dummy Block. Take into account this scenario to avoid
failing id it occurs.
Change-Id: I30da93835c7738aefcd84691d83f39759dd4b599
---
M pcu/PCU_Tests.ttcn
1 file changed, 10 insertions(+), 2 deletions(-)
Approvals:
Jenkins Builder: Verified
fixeria: Looks good to me, approved
diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 4b909c7..876b282 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -3627,8 +3627,16 @@
BSSGP[0].send(ts_BSSGP_CS_PAGING_IMSI(bvci, imsi));
}
- /* Receive it on BTS side towards MS */
- f_rx_rlcmac_dl_block_exp_pkt_pag_req(dl_block);
+ /* Now receive it on BTS side towards MS.
+ * Skip any dummy blocks in case the PCUIF req arrives before the BSSP CS_PAGING:
+ */
+ f_rx_rlcmac_dl_block_skip_dummy(dl_block, max_dummy := 10);
+
+ if (not match(dl_block, tr_RLCMAC_PACKET_PAG_REQ())) {
+ setverdict(fail, "Failed to match Packet Paging Request: ",
+ dl_block, " vs ", tr_RLCMAC_PACKET_PAG_REQ());
+ f_shutdown(__BFILE__, __LINE__);
+ }
/* Make sure that Packet Paging Request contains the same P-TMSI/IMSI */
var PacketPagingReq req := dl_block.ctrl.payload.u.paging;
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30374
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: I30da93835c7738aefcd84691d83f39759dd4b599
Gerrit-Change-Number: 30374
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30373 )
Change subject: pcu: TC_mt_ping_pong*: Fix race condition waiting for first DL data after X2002
......................................................................
pcu: TC_mt_ping_pong*: Fix race condition waiting for first DL data after X2002
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: Icc94eb0544226facddcd65be65a8a41bcfc662cc
---
M pcu/PCU_Tests.ttcn
1 file changed, 4 insertions(+), 1 deletion(-)
Approvals:
Jenkins Builder: Verified
fixeria: Looks good to me, approved
diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 936f101..4b909c7 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -2573,7 +2573,10 @@
/* Wait timer X2002 and DL block is available after CCCH IMM ASS: */
f_sleep(X2002);
- f_rx_rlcmac_dl_block_exp_data(dl_block, dl_fn, data, 0, exp_cs_mcs);
+ /* Skip potential dummy blocks before X2002 triggers at PCU after us: */
+ dl_fn := f_rx_rlcmac_dl_block_skip_dummy(dl_block, max_dummy := 10);
+
+ f_rlcmac_dl_block_exp_data(dl_block, data, 0, exp_cs_mcs);
/* ACK the DL block, and request UL TBF at the same time */
f_dltbf_ack_block(ms.dl_tbf, dl_block, '1'B);
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30373
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: Icc94eb0544226facddcd65be65a8a41bcfc662cc
Gerrit-Change-Number: 30373
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30371 )
Change subject: pcu: Fix race condition in TC_cs_max_dl waiting for timer first DL data after X2002
......................................................................
pcu: Fix race condition in TC_cs_max_dl waiting for timer first DL data after X2002
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state.
Change-Id: If7121473a3580b40d3a658dc38b9bb1421196127
---
M pcu/GPRS_Components.ttcn
M pcu/PCU_Tests.ttcn
2 files changed, 28 insertions(+), 1 deletion(-)
Approvals:
Jenkins Builder: Verified
fixeria: Looks good to me, but someone else must approve
laforge: Looks good to me, approved
diff --git a/pcu/GPRS_Components.ttcn b/pcu/GPRS_Components.ttcn
index e248860..37dcc97 100644
--- a/pcu/GPRS_Components.ttcn
+++ b/pcu/GPRS_Components.ttcn
@@ -1200,6 +1200,30 @@
return dl_fn;
}
+/* Keep getting dl_block until first non RLCMAC Dummy is received, then return it */
+function f_rx_rlcmac_dl_block_skip_dummy(out RlcmacDlBlock dl_block,
+ integer max_dummy := -1,
+ template (value) TsTrxBtsNum nr := ts_TsTrxBtsNum)
+runs on MS_BTS_IFACE_CT return uint32_t {
+ var integer i;
+ var uint32_t dl_fn;
+
+ while (true) {
+ f_rx_rlcmac_dl_block(dl_block, dl_fn, nr := nr);
+ if (not match(dl_block, tr_RLCMAC_DL_DUMMY_CTRL)) {
+ /* Received first data, starting processing: */
+ break;
+ }
+ i := i + 1;
+ if (max_dummy >= 0 and i > max_dummy) {
+ setverdict(fail, "Didn't receive DL data after receiving ", i, " dummy blocks");
+ f_shutdown(__BFILE__, __LINE__);
+ break;
+ }
+ }
+ return dl_fn;
+}
+
function f_rx_rlcmac_dl_block_exp_pkt_pag_req(out RlcmacDlBlock dl_block,
template (value) TsTrxBtsNum nr := ts_TsTrxBtsNum)
runs on MS_BTS_IFACE_CT {
diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index af84821..38c50be 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -1089,9 +1089,11 @@
/* Wait timer X2002 and DL block is available after CCCH IMM ASS */
f_sleep(X2002);
+ /* Skip potential dummy blocks before X2002 triggers at PCU after us: */
+ fn := f_rx_rlcmac_dl_block_skip_dummy(dl_block, max_dummy := 10);
+
for (var integer i := 0; i < 800; i := i + 1) {
bsn := i mod bsn_mod;
- f_rx_rlcmac_dl_block(dl_block, fn);
if (match(dl_block, tr_RLCMAC_DL_DUMMY_CTRL)) {
/* No more data to receive, done */
@@ -1114,6 +1116,7 @@
}
}
prev_dl_block := dl_block;
+ f_rx_rlcmac_dl_block(dl_block, fn);
}
bsn := (bsn + (bsn_mod-1)) mod bsn_mod; /* previous bsn: bsn -1 */
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30371
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: If7121473a3580b40d3a658dc38b9bb1421196127
Gerrit-Change-Number: 30371
Gerrit-PatchSet: 3
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30372 )
Change subject: pcu: TC_dl_flow_more_blocks: Fix race condition waiting for first DL data after X2002
......................................................................
pcu: TC_dl_flow_more_blocks: Fix race condition waiting for first DL data after X2002
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: I67483bc423567d1fc98eb912ece1cf5cda746119
---
M pcu/PCU_Tests.ttcn
1 file changed, 3 insertions(+), 1 deletion(-)
Approvals:
Jenkins Builder: Verified
fixeria: Looks good to me, approved
diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 38c50be..936f101 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -2773,9 +2773,11 @@
/* Wait timer X2002 and DL block is available after CCCH IMM ASS */
f_sleep(X2002);
+ /* Skip potential dummy blocks before X2002 triggers at PCU after us: */
+ fn := f_rx_rlcmac_dl_block_skip_dummy(dl_block, max_dummy := 10);
/* Expect the first (GPRS DL) block with bsn=0 and rrbp_valid=1 */
- f_rx_rlcmac_dl_block_exp_data(dl_block, fn, data, 0);
+ f_rlcmac_dl_block_exp_data(dl_block, data, 0);
f_acknackdesc_ack_block(ms.dl_tbf.acknack_desc, dl_block);
/* TDMA frame number on which we are supposed to send the ACK */
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30372
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: I67483bc423567d1fc98eb912ece1cf5cda746119
Gerrit-Change-Number: 30372
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
Attention is currently required from: pespin.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30371 )
Change subject: pcu: Fix race condition in TC_cs_max_dl waiting for timer first DL data after X2002
......................................................................
Patch Set 3: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30371
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: If7121473a3580b40d3a658dc38b9bb1421196127
Gerrit-Change-Number: 30371
Gerrit-PatchSet: 3
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 02 Dec 2022 16:25:35 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment