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

[S] Change in osmo-ccid-firmware[master]: ccid: reject invalid bClockCommand
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42778?usp=email ) Change subject: ccid: reject invalid bClockCommand ...................................................................... ccid: reject invalid bClockCommand Change-Id: I34dedcaaaf3cd67e22b207016f08e745736dd625 --- M ccid_common/ccid_device.c 1 file changed, 9 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/78/42778/1 diff --git a/ccid_common/ccid_device.c b/ccid_common/ccid_device.c index 63a4d70..d9faa00 100644 --- a/ccid_common/ccid_device.c +++ b/ccid_common/ccid_device.c @@ -601,9 +601,17 @@ const union ccid_pc_to_rdr *u = msgb_ccid_out(msg); const struct ccid_header *ch = (const struct ccid_header *) u; uint8_t seq = u->icc_clock.hdr.bSeq; + uint8_t cmd = u->icc_clock.bClockCommand; struct msgb *resp; - cs->ci->slot_ops->set_clock(cs, u->icc_clock.bClockCommand); + /* CCID v1.1 §6.1.9: bClockCommand has only two defined values; reject + * early here */ + if (cmd != CCID_CLOCK_CMD_RESTART && cmd != CCID_CLOCK_CMD_STOP) { + resp = ccid_gen_slot_status(cs, seq, CCID_CMD_STATUS_FAILED, offsetof(struct ccid_pc_to_rdr_icc_clock, bClockCommand)); + return ccid_slot_send_unbusy(cs, resp); + } + + cs->ci->slot_ops->set_clock(cs, cmd); resp = ccid_gen_slot_status(cs, seq, CCID_CMD_STATUS_OK, 0); return ccid_slot_send_unbusy(cs, resp); } -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42778?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: I34dedcaaaf3cd67e22b207016f08e745736dd625 Gerrit-Change-Number: 42778 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[XS] Change in osmo-ccid-firmware[master]: cuart: Fix waiting time to be per-byte instead of total timeout
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42777?usp=email ) Change subject: cuart: Fix waiting time to be per-byte instead of total timeout ...................................................................... cuart: Fix waiting time to be per-byte instead of total timeout The previous code multiplied WT by the number of expected bytes, creating a total timeout proportional to the transfer size. This works fine for (currently unsupported) high baud rates, but it makes it look like the reader "freezes" at default rates due to the very long delay. Just reset it upon rx and do not multiply it so it behaves as expected. Closes:OS#7012 Change-Id: Ic00040b88e1b204db3f4f3edad09878aa28d35a1 --- M ccid_common/cuart.c M sysmoOCTSIM/cuart_driver_asf4_usart_async.c 2 files changed, 5 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/77/42777/1 diff --git a/ccid_common/cuart.c b/ccid_common/cuart.c index bb17c4b..737a392 100644 --- a/ccid_common/cuart.c +++ b/ccid_common/cuart.c @@ -63,8 +63,9 @@ int etu_in_us = get_etu_in_us(cuart) + 1; cuart->wtime_etu = cuart->wtime_etu ? cuart->wtime_etu : 1; - /* timeout is wtime * ETU * expected number of bytes */ - uint32_t usecs = etu_in_us * cuart->wtime_etu * cuart->current_wtime_byte; + /* ISO 7816-3 Section 10.2: WT is the max delay between consecutive + * characters, not a total transfer timeout. Restart on each byte. */ + uint32_t usecs = etu_in_us * cuart->wtime_etu; /* limit lower wait time to reasonable value */ if (usecs < 300000) diff --git a/sysmoOCTSIM/cuart_driver_asf4_usart_async.c b/sysmoOCTSIM/cuart_driver_asf4_usart_async.c index 42c2110..8330523 100644 --- a/sysmoOCTSIM/cuart_driver_asf4_usart_async.c +++ b/sysmoOCTSIM/cuart_driver_asf4_usart_async.c @@ -32,6 +32,8 @@ int rc; OSMO_ASSERT(cuart); + card_uart_wtime_restart(cuart); + if (cuart->rx_threshold == 1) { /* bypass ringbuffer and report byte directly */ uint8_t rx[1]; -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42777?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Ic00040b88e1b204db3f4f3edad09878aa28d35a1 Gerrit-Change-Number: 42777 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[S] Change in osmo-ccid-firmware[master]: 7816fsm: fail PPS on invalid first byte in PPS_S_WAIT_PPSX
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42780?usp=email ) Change subject: 7816fsm: fail PPS on invalid first byte in PPS_S_WAIT_PPSX ...................................................................... 7816fsm: fail PPS on invalid first byte in PPS_S_WAIT_PPSX Change-Id: I5b74b8443a98224c0c95a664a886066495d8b64a --- M ccid_common/iso7816_fsm.c 1 file changed, 15 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/80/42780/1 diff --git a/ccid_common/iso7816_fsm.c b/ccid_common/iso7816_fsm.c index ffa895e..407c1fb 100644 --- a/ccid_common/iso7816_fsm.c +++ b/ccid_common/iso7816_fsm.c @@ -1076,8 +1076,22 @@ msgb_put_u8(atp->rx_cmd, byte); switch (fi->state) { case PPS_S_WAIT_PPSX: - if (byte == 0xff) + /* ISO 7816-3 §9.2: PPSS is fixed at 0xff. Any other + * first byte is an erroneous PPS response and §9.1 + * requires deactivation. We must transition out of + * WAIT_PPSX on every byte like every other PPS substate + * so the unconditional msgb_put_u8 above stays + * bounded by the spec's 6-byte maximum. */ + if (byte == 0xff) { osmo_fsm_inst_state_chg(fi, PPS_S_WAIT_PPS0, 0, 0); + } else { + LOGPFSML(fi, LOGL_ERROR, + "Invalid PPSS=0x%02x (expected 0xff); failing PPS\n", + byte); + osmo_fsm_inst_state_chg(fi, PPS_S_DONE, 0, 0); + osmo_fsm_inst_dispatch(fi->proc.parent, + ISO7816_E_PPS_FAILED_IND, atp->tx_cmd); + } break; case PPS_S_WAIT_PPS0: atp->pps0_recv = byte; -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42780?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: I5b74b8443a98224c0c95a664a886066495d8b64a Gerrit-Change-Number: 42780 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[S] Change in osmo-ccid-firmware[master]: 7816fsm: Handle unexpected procedure bytes gracefully
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42776?usp=email ) Change subject: 7816fsm: Handle unexpected procedure bytes gracefully ...................................................................... 7816fsm: Handle unexpected procedure bytes gracefully Dispatch TPDU_FAILED_IND and don't assert for wrong procedure bytes. Closes:SYS#8050 Change-Id: Ic53814540775f902fce644a5565a7bd2f177a7fe --- M ccid_common/iso7816_fsm.c 1 file changed, 7 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/76/42776/1 diff --git a/ccid_common/iso7816_fsm.c b/ccid_common/iso7816_fsm.c index bad827a..3202a80 100644 --- a/ccid_common/iso7816_fsm.c +++ b/ccid_common/iso7816_fsm.c @@ -1370,8 +1370,11 @@ card_uart_ctrl(ip->uart, CUART_CTL_RX_TIMER_HINT, 1); osmo_fsm_inst_state_chg(fi, TPDU_S_RX_SINGLE, 0, 0); } - } else - OSMO_ASSERT(0); + } else { + LOGPFSML(fi, LOGL_ERROR, "Unexpected byte 0x%02x in procedure state (INS=0x%02x)\n", byte, tpduh->ins); + osmo_fsm_inst_state_chg(fi, TPDU_S_DONE, 0, 0); + osmo_fsm_inst_dispatch(fi->proc.parent, ISO7816_E_TPDU_FAILED_IND, tfp->tpdu); + } break; default: OSMO_ASSERT(0); @@ -1588,7 +1591,8 @@ S(TPDU_S_RX_SINGLE) | S(TPDU_S_TX_REMAINING) | S(TPDU_S_TX_SINGLE) | - S(TPDU_S_SW2), + S(TPDU_S_SW2) | + S(TPDU_S_DONE), .action = tpdu_s_procedure_action, }, [TPDU_S_TX_REMAINING] = { -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42776?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Ic53814540775f902fce644a5565a7bd2f177a7fe Gerrit-Change-Number: 42776 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[XS] Change in osmo-ccid-firmware[master]: 7816fsm: state_chg before card_uart_tx in tpdu_s_procedure_action
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42781?usp=email ) Change subject: 7816fsm: state_chg before card_uart_tx in tpdu_s_procedure_action ...................................................................... 7816fsm: state_chg before card_uart_tx in tpdu_s_procedure_action State change must precede the TX to ensure we don't lose TX_COMPLETE notifications that arrive at a bad time. Change-Id: Id66f836452674209e25dc3ee4c37d616de30001b --- M ccid_common/iso7816_fsm.c 1 file changed, 2 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/81/42781/1 diff --git a/ccid_common/iso7816_fsm.c b/ccid_common/iso7816_fsm.c index 407c1fb..9899e16 100644 --- a/ccid_common/iso7816_fsm.c +++ b/ccid_common/iso7816_fsm.c @@ -1371,8 +1371,8 @@ delay_us(1); gpio_set_pin_level(PIN_PB12, false); #endif - card_uart_tx(ip->uart, msgb_l2(tfp->tpdu), msgb_l2len(tfp->tpdu), true); osmo_fsm_inst_state_chg(fi, TPDU_S_TX_REMAINING, 0, 0); + card_uart_tx(ip->uart, msgb_l2(tfp->tpdu), msgb_l2len(tfp->tpdu), true); } else { /* 7816-3 10.3.2 special case outgoing transfer 0 means 256 */ int len_expected = tpduh->p3 == 0 ? 256 : tpduh->p3; @@ -1391,8 +1391,8 @@ if (tfp->is_command) { /* transmit *next*, not first byte */ OSMO_ASSERT(msgb_l3len(tfp->tpdu) >= 0); - card_uart_tx(ip->uart, msgb_l3(tfp->tpdu), 1, false); osmo_fsm_inst_state_chg(fi, TPDU_S_TX_SINGLE, 0, 0); + card_uart_tx(ip->uart, msgb_l3(tfp->tpdu), 1, false); } else { card_uart_set_rx_threshold(ip->uart, 1); card_uart_ctrl(ip->uart, CUART_CTL_RX_TIMER_HINT, 1); -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42781?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Id66f836452674209e25dc3ee4c37d616de30001b Gerrit-Change-Number: 42781 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[S] Change in osmo-ccid-firmware[master]: 7816fsm: reset stale cuart state on FSM RESET entry
by Hoernchen 28 May '26

28 May '26

Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42779?usp=email ) Change subject: 7816fsm: reset stale cuart state on FSM RESET entry ...................................................................... 7816fsm: reset stale cuart state on FSM RESET entry Reset paths reached without power-cycling (WTIME_EXP, HW_ERR, CARD_REMOVAL during a warm reset) leave the cuart with stale tx_busy, rx_threshold and wtime_etu from the prior transaction. The next ATR then hits card_uart_tx tx_busy assertion, or the ATR receive stalls because the 33-byte ATR can never reach a multi-byte rx_threshold left from a TPDU. The new card_uart_tx_abort() clears tx_busy + rx_after_tx_compl + WT, without driving a synthetic TX_COMPLETE through the FSM. iso7816_3_reset_onenter is the right place to do this alongside rx_threshold=1 and wtime_etu=default, this mirrors what card_uart_ctrl(POWER_*=0) already does, but for the warm-reset paths that don't touch power. Change-Id: Iac8bd7f4f0eecccc9acce149277a4f5016fec7c1 --- M ccid_common/ccid_slot_fsm.c M ccid_common/cuart.c M ccid_common/cuart.h M ccid_common/iso7816_fsm.c 4 files changed, 40 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ccid-firmware refs/changes/79/42779/1 diff --git a/ccid_common/ccid_slot_fsm.c b/ccid_common/ccid_slot_fsm.c index 22d3f70..fae2c3b 100644 --- a/ccid_common/ccid_slot_fsm.c +++ b/ccid_common/ccid_slot_fsm.c @@ -54,6 +54,8 @@ static struct iso_fsm_slot_instance g_si; +static void iso_fsm_slot_abort(struct ccid_slot *cs); + static struct iso_fsm_slot *ccid_slot2iso_fsm_slot(struct ccid_slot *cs) { OSMO_ASSERT(cs->slot_nr < ARRAY_SIZE(g_si.slot)); diff --git a/ccid_common/cuart.c b/ccid_common/cuart.c index 737a392..bb47da4 100644 --- a/ccid_common/cuart.c +++ b/ccid_common/cuart.c @@ -167,6 +167,24 @@ return rc; } +/*! Abort any in-flight TX on the cuart side. + * + * Clears tx_busy and rx_after_tx_compl without driving CUART_E_TX_COMPLETE + * through the FSM. Use this when the layer above (the ISO 7816-3 FSM) has + * given up on the current transaction (e.g. WTIME / HW_ERR / CARD_REMOVAL) + * and is moving to reset state. Any in-flight hardware TX is no longer of + * interest to the FSM; if the driver-level DMA happens to complete later, + * the resulting TX_COMPLETE notification will see tx_busy already false + * and rx_after_tx_compl already false, so it won't spuriously re-enable + * the receiver. */ +void card_uart_tx_abort(struct card_uart *cuart) +{ + OSMO_ASSERT(cuart); + card_uart_wtime_stop(cuart); + cuart->tx_busy = false; + cuart->rx_after_tx_compl = false; +} + int card_uart_tx(struct card_uart *cuart, const uint8_t *data, size_t len, bool rx_after_complete) { OSMO_ASSERT(cuart); diff --git a/ccid_common/cuart.h b/ccid_common/cuart.h index a9afc1d..a53dc18 100644 --- a/ccid_common/cuart.h +++ b/ccid_common/cuart.h @@ -153,6 +153,12 @@ /*! Schedule (asynchronous) transmit data via UART; optionally enable Rx after completion */ int card_uart_tx(struct card_uart *cuart, const uint8_t *data, size_t len, bool rx_after_complete); +/*! Abort any in-flight TX. Clears tx_busy + stops WT timer. Used by the + * ISO7816-3 FSM when transitioning to RESET, so subsequent transactions + * don't trip card_uart_tx's "TX already in flight" assertion on the stale + * tx_busy left behind by an aborted transfer. */ +void card_uart_tx_abort(struct card_uart *cuart); + /*! Schedule (asynchronous) receive data via UART (after CUART_E_RX_COMPLETE) */ int card_uart_rx(struct card_uart *cuart, uint8_t *data, size_t len); diff --git a/ccid_common/iso7816_fsm.c b/ccid_common/iso7816_fsm.c index 3202a80..ffa895e 100644 --- a/ccid_common/iso7816_fsm.c +++ b/ccid_common/iso7816_fsm.c @@ -31,6 +31,7 @@ #include "logging.h" #include "cuart.h" +#include "iso7816_3.h" #include "iso7816_fsm.h" /* unionize to ensure at least properly aligned msgb struct */ @@ -312,7 +313,20 @@ struct iso7816_3_priv *ip = get_iso7816_3_priv(fi); OSMO_ASSERT(fi->fsm == &iso7816_3_fsm); + /* Bring the cuart back to its default per-transaction state, matching + * what card_uart_ctrl(CUART_CTL_POWER_*, 0) does, but without + * power-cycling (warm reset, HW_ERR, WTIME paths reach S_RESET without + * touching power). Any reset path could land here mid-transaction with + * stale state: tx_busy still set from an aborted TX, rx_threshold left + * at e.g. 256 from a multi-byte RX setup, wtime_etu still at a + * PPS-negotiated value rather than the ATR default. Leaving those + * stale breaks the next ATR (next card_uart_tx asserts; or ATR bytes + * pile up in the ringbuffer waiting for a threshold that ATR's max 33 + * bytes can never reach). */ card_uart_ctrl(ip->uart, CUART_CTL_RX_TIMER_HINT, 0); + card_uart_tx_abort(ip->uart); + card_uart_set_rx_threshold(ip->uart, 1); + card_uart_ctrl(ip->uart, CUART_CTL_WTIME, ISO7816_3_DEFAULT_WT); /* go back to initial state in child FSMs */ osmo_fsm_inst_state_chg(ip->atr_fi, ATR_S_WAIT_TS, 0, 0); -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42779?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Iac8bd7f4f0eecccc9acce149277a4f5016fec7c1 Gerrit-Change-Number: 42779 Gerrit-PatchSet: 1 Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>

1 0

[M] Change in pysim[master]: personalization: implement UppAudit and BatchAudit
by laforge 28 May '26

28 May '26

Attention is currently required from: fixeria, neels. laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/40208?usp=email ) Change subject: personalization: implement UppAudit and BatchAudit ...................................................................... Patch Set 11: (1 comment) File pySim/esim/saip/batch.py: https://gerrit.osmocom.org/c/pysim/+/40208/comment/6c49f0cd_2bfd71ea?usp=em… : PS11, Line 143: {'001010000000023'} > To me, the "single USIM NAA and single ISIM NAA" is the common case, and whatever we do should suppo […] Just to clarify: I think it's fine to not support multiple USIM NAA and/or multipel ISIM NAA for now. That's what I meant with "seemingly esoteric". -- To view, visit https://gerrit.osmocom.org/c/pysim/+/40208?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: Iaab336ca91b483ecdddd5c6c8e08dc475dc6bd0a Gerrit-Change-Number: 40208 Gerrit-PatchSet: 11 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 May 2026 10:07:14 +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]: personalization: implement UppAudit and BatchAudit
by laforge 28 May '26

28 May '26

Attention is currently required from: fixeria, neels. laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/40208?usp=email ) Change subject: personalization: implement UppAudit and BatchAudit ...................................................................... Patch Set 11: (1 comment) File pySim/esim/saip/batch.py: https://gerrit.osmocom.org/c/pysim/+/40208/comment/312edcb2_f467d0a3?usp=em… : PS11, Line 143: {'001010000000023'} > Ok, I wasn't aware of the possibility... […] To me, the "single USIM NAA and single ISIM NAA" is the common case, and whatever we do should support this. This most definitely includes the sysmo-esim-mgr, and I would so far have assumed that if the IMSI is personalized there, it will be personalized in the ADF.USIM and automagically, if an ADF.ISIM/EF.IMSI exists, also there. If not, it is quite simply broken. The "multiple USIM and/or multiple ISIM NAAs in a single profile" is a to me seemingly esoteric option in the standard, but there must be valid use cases as real-world eUICCs like I think the sysmoEUICC1 actually do support it. The EUICCs actually indicate the support of this optional feature to the SM-DP+ during the mutual authentication phase, so the SM-DP+ can ensure to provide compatible profiles. I still believe our code should be safe. So if we do not support multiple USIM NAAs or multiple ISIM NAAs from the audit code (or any other part of the code), it should safely abort and refuse to proceed with such a PESequence as input data. The way to do this in python is raising an exception. This way a user [of the API / module] cannot end up with an invalid/non-applicable uadit result, or with something that's only half personalized. It will have zero implications on sysmo-esim-mgr as long as we are smart enough not to give it input PEsequences that us features which our code doesn't support. And if we ever forget that constraint, it will fail and we will notice it. I'm not very happy about your "but this is used in production so let's merge something that hasn't really been discussed during it's design" argument. To me it just illustrates once more that having dragged along this way past due code review is causing downstream problems. Review of this code, including any of its possible constraints, should have happened as the first step *before* sysmo-esim-mgr is written or at least has gone public. But that's not something we can change now or need to debat here. Simply indicating that I'm a bit allergic to that kind of argument. Regarding your 'morge complex idea': Yes, that is how I would think is the way to go. And if we want to avoid breaking applications later on, we could make the current code already generate the output in this format. Even if it only supports a single ISMI in ADF.USIM and optionally one in ADF.ISIM, it could generate a format that later on can be augmented with more data as our pySim.esim.saip module becomes more mature. Up to you if you think it makes sense to change that now and avoid future breakage in the returned data format. -- To view, visit https://gerrit.osmocom.org/c/pysim/+/40208?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: Iaab336ca91b483ecdddd5c6c8e08dc475dc6bd0a Gerrit-Change-Number: 40208 Gerrit-PatchSet: 11 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 May 2026 10:06:01 +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 libosmo-sigtran[master]: tcap loadshare: allow to define the fallback mechanism for unroutable...
by lynxis lazus 28 May '26

28 May '26

Attention is currently required from: laforge, pespin. lynxis lazus has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42760?usp=email ) Change subject: tcap loadshare: allow to define the fallback mechanism for unroutable TCAP messages ...................................................................... Patch Set 8: (2 comments) File src/tcap_as_loadshare.c: https://gerrit.osmocom.org/c/libosmo-sigtran/+/42760/comment/a3c00ef0_3dee3… : PS3, Line 257: static struct osmo_ss7_asp *select_asp_tcap_enabled_rr(struct osmo_ss7_as *as, bool fallback) > ok, will change it. Done https://gerrit.osmocom.org/c/libosmo-sigtran/+/42760/comment/560bd898_e65e6… : PS3, Line 556: asp = select_asp_tcap_enabled_rr(as, true); > yes, you're right. Done -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42760?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-sigtran Gerrit-Branch: master Gerrit-Change-Id: Ic1c876da30b05065a476d3a7c1bbf0680adf55bd Gerrit-Change-Number: 42760 Gerrit-PatchSet: 8 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-Comment-Date: Thu, 28 May 2026 10:03:15 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: lynxis lazus <lynxis(a)fe80.eu>

1 0

[S] Change in libosmo-sigtran[master]: tcap loadshare: Rework initial selection of a node
by lynxis lazus 28 May '26

28 May '26

Attention is currently required from: pespin. lynxis lazus has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42755?usp=email ) Change subject: tcap loadshare: Rework initial selection of a node ...................................................................... Patch Set 3: (1 comment) File src/tcap_as_loadshare.c: https://gerrit.osmocom.org/c/libosmo-sigtran/+/42755/comment/55afa402_1806d… : PS3, Line 525: asp = select_asp_tcap_enabled_rr(as); > I fail to see where the tcap range is used in the Begin now, but if you say it's there then fine for […] No, it isn't used anymore when using begin. -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42755?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-sigtran Gerrit-Branch: master Gerrit-Change-Id: I151e6acb59e1f3c481487e76d2b01236fcee755f Gerrit-Change-Number: 42755 Gerrit-PatchSet: 3 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 May 2026 10:01:42 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: lynxis lazus <lynxis(a)fe80.eu>

1 0

2026

2025

2024

2023

2022

gerrit-log May 2026