June 2026 - gerrit-log - lists.osmocom.org

[S] Change in osmo-pcap[master]: tls: fix broken certificate hostname verification
by pespin 23 Jun '26

23 Jun '26

Attention is currently required from: fixeria. pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-pcap/+/42849?usp=email ) Change subject: tls: fix broken certificate hostname verification ...................................................................... Patch Set 4: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-pcap/+/42849?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Change-Id: If64950a698bfcfbf556a37ef1be3e68abc124384 Gerrit-Change-Number: 42849 Gerrit-PatchSet: 4 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Tue, 23 Jun 2026 20:28:35 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[M] Change in pysim[master]: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a...
by laforge 23 Jun '26

23 Jun '26

Attention is currently required from: fixeria, neels, pespin. laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/42829?usp=email ) Change subject: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a-x25519, profile-b-p256 ...................................................................... Patch Set 4: (1 comment) File pySim/esim/saip/__init__.py: https://gerrit.osmocom.org/c/pysim/+/42829/comment/8ce0653b_c940ae09?usp=em… : PS4, Line 1737: So, when SUCI-CalcInfo for USIM in DF.SAIP contains both key types, : # then no profile-A or B services need to be requested explicitly. > The MNO has zero visibility of the eUICC capability. […] In the real world, to be fair, I expect most opreators will only use either A or B. But then, nothing in the spec that I know of requires them to make an either-or choice. -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42829?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: Ibc29c6437c5c92e2b14938b733156536863465c1 Gerrit-Change-Number: 42829 Gerrit-PatchSet: 4 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: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 23 Jun 2026 20:09:11 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[M] Change in pysim[master]: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a...
by laforge 23 Jun '26

23 Jun '26

Attention is currently required from: fixeria, neels, pespin. laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/42829?usp=email ) Change subject: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a-x25519, profile-b-p256 ...................................................................... Patch Set 4: (1 comment) File pySim/esim/saip/__init__.py: https://gerrit.osmocom.org/c/pysim/+/42829/comment/ae007c8e_acacf88f?usp=em… : PS4, Line 1737: So, when SUCI-CalcInfo for USIM in DF.SAIP contains both key types, : # then no profile-A or B services need to be requested explicitly. > i see, so far i had a viewpoint of wide compatibility, sort of like voice codec choices: […] The MNO has zero visibility of the eUICC capability. How would he have that? I think that's the key aspect here. The MNO only knows what they put into the profile. Think of it from a classic USIM issuing situation: IF the operator deploys a USIM with keys for profile-a and profile-b, they would only do that if they know (based on a-priori knowledge of the USIM data sheet) that both are supported. They would also likely test that, at least if they have proper testing coverage. in terms of eUICCs, the MNO has no idea whihc chip with what OS and whcih capabilities ends up being soldered into device X of vendor Z. The MNO also usually is not the SM-DP+ operator, but the SM-DP+ is only operated by a sub-contracted SaaS eSIM provider. There is no standard interface by which the MNO would know about the individual capabilities of each eUICC. There is no standard database in which a MNO would track such capabilities. And last, but not least, I'm not aware of any 3GPP standardizd interface or feature influencing whatever 5GC elements that make the key selection. -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42829?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: Ibc29c6437c5c92e2b14938b733156536863465c1 Gerrit-Change-Number: 42829 Gerrit-PatchSet: 4 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: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 23 Jun 2026 20:08:27 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[S] Change in osmo-bts[master]: osmo-bts-trx: fix spurious shutdown on first CLCK.ind from osmo-trx
by fixeria 23 Jun '26

23 Jun '26

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/42871?usp=email ) Change subject: osmo-bts-trx: fix spurious shutdown on first CLCK.ind from osmo-trx ...................................................................... osmo-bts-trx: fix spurious shutdown on first CLCK.ind from osmo-trx osmo-trx starts its frame counter from a random value rather than 0. When the first CLCK.ind arrives, last_fn_timer and last_clk_ind are still zero-initialised (set by trx_sched_clock_started()), so: * compute_elapsed_fn(0, fn) wraps to a large negative for any fn greater than hyperframe/2 (1357824), satisfying elapsed_fn < 0; * compute_elapsed_us({0,0}, &tv_now) returns the full CLOCK_MONOTONIC uptime (potentially days), satisfying the error_us threshold. Together these trip the stale-clock shutdown introduced in the previous commit (0199c108), even though the transceiver is perfectly healthy: DL1C NOTICE scheduler_trx.c:490 GSM clock started, waiting for clock indications DL1C FATAL scheduler_trx.c:589 Stale CLCK.ind: fn=1456348 is 250957770198 us behind DOML NOTICE bts_shutdown_fsm.c:268 BTS_SHUTDOWN(bts0){NONE}: Shutting down BTS, exit 1, reason: TRX clock skew too high Fix by adding clk_ind_received to osmo_trx_clock_state. On the first CLCK.ind after a (re)start, skip all elapsed-time checks and directly bootstrap the scheduler from the reported FN. The stale-clock detection remains fully active for every subsequent indication, where last_clk_ind holds a real baseline. Change-Id: I25e76e02d29fd8f88130d15d0adfe8d90a017924 Fixes: 0199c108 ("osmo-bts-trx: shut down on stale clock indication from transceiver") Related: OS#7021 --- M src/osmo-bts-trx/l1_if.h M src/osmo-bts-trx/scheduler_trx.c 2 files changed, 15 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/71/42871/1 diff --git a/src/osmo-bts-trx/l1_if.h b/src/osmo-bts-trx/l1_if.h index 09bf7ac..d0a1347 100644 --- a/src/osmo-bts-trx/l1_if.h +++ b/src/osmo-bts-trx/l1_if.h @@ -39,6 +39,8 @@ struct osmo_trx_clock_state { /*! number of FN periods without TRX clock indication */ uint32_t fn_without_clock_ind; + /*! set to true once the first clock indication has been received */ + bool clk_ind_received; struct { /*! last FN we processed based on FN period timer */ uint32_t fn; diff --git a/src/osmo-bts-trx/scheduler_trx.c b/src/osmo-bts-trx/scheduler_trx.c index 105ad38..a4585ae 100644 --- a/src/osmo-bts-trx/scheduler_trx.c +++ b/src/osmo-bts-trx/scheduler_trx.c @@ -545,6 +545,19 @@ clock_gettime(CLOCK_MONOTONIC, &tv_now); + /* First clock indication after (re)start: bootstrap the clock from whatever + * FN the transceiver reports. osmo-trx starts its frame counter from a + * random value, so elapsed_fn and elapsed_us comparisons against the + * zero-initialised last_fn_timer / last_clk_ind would be nonsensical and + * would incorrectly trigger the stale-clock shutdown path. */ + if (!tcs->clk_ind_received) { + LOGP(DL1C, LOGL_NOTICE, "GSM clock started: first CLCK.ind fn=%u\n", fn); + tcs->last_clk_ind.tv = tv_now; + tcs->last_clk_ind.fn = fn; + tcs->clk_ind_received = true; + return trx_setup_clock(bts, tcs, &tv_now, &interval, fn); + } + /* calculate elapsed time +fn since last timer */ elapsed_us = compute_elapsed_us(&tcs->last_fn_timer.tv, &tv_now); elapsed_fn = compute_elapsed_fn(tcs->last_fn_timer.fn, fn); -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/42871?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I25e76e02d29fd8f88130d15d0adfe8d90a017924 Gerrit-Change-Number: 42871 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

1 0

[M] Change in pysim[master]: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a...
by neels 23 Jun '26

23 Jun '26

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/42829?usp=email ) Change subject: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a-x25519, profile-b-p256 ...................................................................... Patch Set 4: (1 comment) File pySim/esim/saip/__init__.py: https://gerrit.osmocom.org/c/pysim/+/42829/comment/6255e569_a049f322?usp=em… : PS4, Line 1737: So, when SUCI-CalcInfo for USIM in DF.SAIP contains both key types, : # then no profile-A or B services need to be requested explicitly. > Your arguments/facts do not contradict my statement. Your comment claims […] i see, so far i had a viewpoint of wide compatibility, sort of like voice codec choices: I imagined, if a eUICC supports only profile-A, and the profile contains both profile-A and profile-B, the eUICC would be happy just using profile-A. But when we mandate both to be supported, the eUICC will reject the profile. I imagined there is agreement across layers on which of the key types is supported by all entities. From that viewpoint, it makes a lot of sense that the spec says "when get-identity is supported, you must support at least one of A or B". Then we can include both and be widely compatible. This convinced me that I am onto something. Also, AFAICT, in the notification-listener logs we can see that all of the eUICC capabilities reported so far are supporting only profile-a-x25519. So I imagine that a profile that *requires* both can hardly be useful to customers. The news for me is that I may have gotten the logic all wrong. I'll adust the logic -- but can you re-confirm please, you are sure that the MNO will switch between keys and require that both are working, without taking into account the eUICC capabilities? Is it maybe two use cases: one for compat and one requiring both? Then it would make sense to have a ConfigurableParameter for the caller to explicitly choose the mandatory-services flags... anyway, I am just guessing and no expert, just making sure. as soon as you confirm what the logic needs to be, i'll adjust it. thanks! -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42829?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: Ibc29c6437c5c92e2b14938b733156536863465c1 Gerrit-Change-Number: 42829 Gerrit-PatchSet: 4 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: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 23 Jun 2026 18:20:16 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[M] Change in osmo-ttcn3-hacks[master]: stp: tcap-loadshare: add TC_tcap_loadshare_m3ua_to_ipa_udts
by daniel 23 Jun '26

23 Jun '26

Attention is currently required from: laforge, lynxis lazus, pespin. daniel has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42824?usp=email ) Change subject: stp: tcap-loadshare: add TC_tcap_loadshare_m3ua_to_ipa_udts ...................................................................... Patch Set 2: Code-Review+1 (1 comment) File stp/STP_Tests_TCAP.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42824/comment/377eace3_8765… : PS1, Line 844: testcase TC_tcap_loadshare_m3ua_to_ipa_udts() runs on TCAP_CT { > Can you please add a descritpion for the test here, like you did in the commit description? Otherwis […] Done -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42824?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I181b25aedfd70d156c08197d361560b6d055e65a Gerrit-Change-Number: 42824 Gerrit-PatchSet: 2 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Comment-Date: Tue, 23 Jun 2026 15:02:22 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-ttcn3-hacks[master]: stp: tcap-loadshare: add TC_tcap_loadshare_m3ua_to_ipa_udts
by lynxis lazus 23 Jun '26

23 Jun '26

Attention is currently required from: laforge, lynxis lazus, pespin. Hello Jenkins Builder, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42824?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Code-Review+1 by laforge, Code-Review+1 by pespin, Verified+1 by Jenkins Builder Change subject: stp: tcap-loadshare: add TC_tcap_loadshare_m3ua_to_ipa_udts ...................................................................... stp: tcap-loadshare: add TC_tcap_loadshare_m3ua_to_ipa_udts If a TCAP message arrives which is: * not a TCAP Begin or Abort (e.g. a TCAP Continue) * not in the TCAP session cache/tracking * not have a dTID for a registered TCAP Add Range The tcap load-share will reject this message with a UDTS Related: SYS#8061 Change-Id: I181b25aedfd70d156c08197d361560b6d055e65a --- M stp/STP_Tests_TCAP.ttcn 1 file changed, 50 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/24/42824/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42824?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I181b25aedfd70d156c08197d361560b6d055e65a Gerrit-Change-Number: 42824 Gerrit-PatchSet: 2 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>

1 0

[M] Change in onomondo-eim[master]: asn1/SGP32Definitions: apply workarounds
by dexter 23 Jun '26

23 Jun '26

Attention is currently required from: jolly. dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email ) Change subject: asn1/SGP32Definitions: apply workarounds ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: Unfortunately the linter complains about trailing whitespaces, however we have to make an exception here. -- To view, visit https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: onomondo-eim Gerrit-Branch: master Gerrit-Change-Id: Id90b005fc3c8c8f737b0c740d4c067f90842a1fe Gerrit-Change-Number: 42870 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: jolly <andreas(a)eversberg.eu> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Comment-Date: Tue, 23 Jun 2026 11:28:36 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[M] Change in onomondo-eim[master]: asn1/SGP32Definitions: apply workarounds
by dexter 23 Jun '26

23 Jun '26

Attention is currently required from: dexter, jolly. dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email ) Change subject: asn1/SGP32Definitions: apply workarounds ...................................................................... Patch Set 1: (1 comment) File asn1/SGP32Definitions.asn1: https://gerrit.osmocom.org/c/onomondo-eim/+/42870/comment/31d4563a_d76ba1b9… : PS1, Line 392: SGP32-EUICCInfo2 ::= [34] SEQUENCE { -- Tag 'BF22' The trailing white-space is part of the original spec, it should be kept in here. -- To view, visit https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: onomondo-eim Gerrit-Branch: master Gerrit-Change-Id: Id90b005fc3c8c8f737b0c740d4c067f90842a1fe Gerrit-Change-Number: 42870 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: jolly <andreas(a)eversberg.eu> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Tue, 23 Jun 2026 11:27:54 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[M] Change in onomondo-eim[master]: asn1/SGP32Definitions: apply workarounds
by Jenkins Builder 23 Jun '26

23 Jun '26

Jenkins Builder has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email ) Change subject: asn1/SGP32Definitions: apply workarounds ...................................................................... Patch Set 1: (1 comment) File asn1/SGP32Definitions.asn1: Robot Comment from checkpatch (run ID ): https://gerrit.osmocom.org/c/onomondo-eim/+/42870/comment/3d2f8b61_cf17a2a6… : PS1, Line 392: SGP32-EUICCInfo2 ::= [34] SEQUENCE { -- Tag 'BF22' trailing whitespace -- To view, visit https://gerrit.osmocom.org/c/onomondo-eim/+/42870?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: onomondo-eim Gerrit-Branch: master Gerrit-Change-Id: Id90b005fc3c8c8f737b0c740d4c067f90842a1fe Gerrit-Change-Number: 42870 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-CC: Jenkins Builder Gerrit-Comment-Date: Tue, 23 Jun 2026 11:25:43 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

2026

2025

2024

2023

2022

gerrit-log June 2026