- gerrit-log - lists.osmocom.org

[S] Change in ...osmo-s1gw[master]: pfcp_peer: replace watchdog process with a timer
by pespin 10 Mar '26

10 Mar '26

Attention is currently required from: fixeria. pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42293?usp=email ) Change subject: pfcp_peer: replace watchdog process with a timer ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42293?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I8d71ad8300feefb0aecbf690a825a2b4e9f1102c Gerrit-Change-Number: 42293 Gerrit-PatchSet: 1 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: Mon, 09 Mar 2026 17:18:58 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[XS] Change in ...osmo-s1gw[master]: s1ap_proxy: fix discarded result of handle_ies/3 in HO REQ ACK handler
by pespin 10 Mar '26

10 Mar '26

Attention is currently required from: fixeria. pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42294?usp=email ) Change subject: s1ap_proxy: fix discarded result of handle_ies/3 in HO REQ ACK handler ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42294?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I1c8feeb63fe23876ae443784980e9dc22a450c54 Gerrit-Change-Number: 42294 Gerrit-PatchSet: 1 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: Mon, 09 Mar 2026 17:18:55 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[S] Change in pysim[master]: pySim/transport: fix GET RESPONSE behaviour
by dexter 10 Mar '26

10 Mar '26

dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/pysim/+/42301?usp=email ) Change subject: pySim/transport: fix GET RESPONSE behaviour ...................................................................... Patch Set 2: (1 comment) File pySim/transport/__init__.py: https://gerrit.osmocom.org/c/pysim/+/42301/comment/1f6121ac_47ab3cb6?usp=em… : PS2, Line 328: le_gr = '00' What confuses me here is that the spec also mentions a 9xxx (but not 9000, and presumably also 9100 as a candidate for this). Technically this seems not to make sense and it also breaks the unit-tests. (for example: 9404, which means FID not found, would also end u here.) -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42301?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: I26f0566af0cdd61dcc97f5f502479dc76adc37cc Gerrit-Change-Number: 42301 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Comment-Date: Mon, 09 Mar 2026 16:03:21 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[S] Change in pysim[master]: pySim/transport: fix GET RESPONSE behaviour
by dexter 10 Mar '26

10 Mar '26

Attention is currently required from: dexter. Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/pysim/+/42301?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified-1 by Jenkins Builder Change subject: pySim/transport: fix GET RESPONSE behaviour ...................................................................... pySim/transport: fix GET RESPONSE behaviour The current behavior we implement in the method __send_apdu_T0 is incomplete. Some details discussed in ETSI TS 102 221, section 7.3.1.1.4, clause 4 seem to be not fully implemented. We may also end up sending a GET RESPONSE in other APDU cases than case 4 (the only case that uses the GET RESPONSE command). Related: OS#6970 Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc --- M pySim/transport/__init__.py 1 file changed, 32 insertions(+), 12 deletions(-) git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/01/42301/2 -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42301?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc Gerrit-Change-Number: 42301 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Attention: dexter <pmaier(a)sysmocom.de>

1 0

[S] Change in pysim[master]: pySim/transport: fix GET RESPONSE behaviour
by Jenkins Builder 10 Mar '26

10 Mar '26

Jenkins Builder has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/pysim/+/42301?usp=email ) Change subject: pySim/transport: fix GET RESPONSE behaviour ...................................................................... Patch Set 1: (2 comments) File pySim/transport/__init__.py: Robot Comment from checkpatch (run ID ): https://gerrit.osmocom.org/c/pysim/+/42301/comment/c3c32089_28532781?usp=em… : PS1, Line 315: # indicates that either no reponse data was returnd or all response data has been retrieved 'reponse' may be misspelled - perhaps 'response'? Robot Comment from checkpatch (run ID ): https://gerrit.osmocom.org/c/pysim/+/42301/comment/2f9fe590_3f637e26?usp=em… : PS1, Line 331: # case we will discontinue the processessing as well. 'processessing' may be misspelled - perhaps 'processing'? -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42301?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: I26f0566af0cdd61dcc97f5f502479dc76adc37cc Gerrit-Change-Number: 42301 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-CC: Jenkins Builder Gerrit-Comment-Date: Mon, 09 Mar 2026 15:23:15 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[S] Change in pysim[master]: pySim/transport: fix GET RESPONSE behaviour
by dexter 10 Mar '26

10 Mar '26

dexter has uploaded this change for review. ( https://gerrit.osmocom.org/c/pysim/+/42301?usp=email ) Change subject: pySim/transport: fix GET RESPONSE behaviour ...................................................................... pySim/transport: fix GET RESPONSE behaviour The current behavior we implement in the method __send_apdu_T0 is incomplete. Some details discussed in ETSI TS 102 221, section 7.3.1.1.4, clause 4 seem to be not fully implemented. We may also end up sending a GET RESPONSE in other APDU cases than case 4 (the only case that uses the GET RESPONSE command). Related: OS#6970 Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc --- M pySim/transport/__init__.py 1 file changed, 32 insertions(+), 12 deletions(-) git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/01/42301/1 diff --git a/pySim/transport/__init__.py b/pySim/transport/__init__.py index f19790c..a8b450f 100644 --- a/pySim/transport/__init__.py +++ b/pySim/transport/__init__.py @@ -302,19 +302,39 @@ prev_tpdu = tpdu data, sw = self.send_tpdu(tpdu) - # When we have sent the first APDU, the SW may indicate that there are response bytes - # available. There are two SWs commonly used for this 9fxx (sim) and 61xx (usim), where - # xx is the number of response bytes available. - # See also: + # After sending the APDU/TPDU the UICC/eUICC or SIM may response with a status word that indicates that further + # TPDUs have to be sent in order to complete the task. if sw is not None: - while (sw[0:2] in ['9f', '61', '62', '63']): - # SW1=9F: 3GPP TS 51.011 9.4.1, Responses to commands which are correctly executed - # SW1=61: ISO/IEC 7816-4, Table 5 — General meaning of the interindustry values of SW1-SW2 - # SW1=62: ETSI TS 102 221 7.3.1.1.4 Clause 4b): 62xx, 63xx, 9xxx != 9000 - tpdu_gr = tpdu[0:2] + 'c00000' + sw[2:4] - prev_tpdu = tpdu_gr - d, sw = self.send_tpdu(tpdu_gr) - data += d + if case is 4: + # In case the APDU is a case #4 APDU (and only in that case), the UICC/eUICC/SIM may indicate that + # there is response data available which has to be retrieved using a GET RESPONSE command TPDU. + # See also: + while True: + if sw in ['9000', '9100']: + # A status word of 9000 (or 9100 in case there is pending data from a proactive SIM command) + # indicates that either no reponse data was returnd or all response data has been retrieved + # successfully. We may discontinue the processing at this point. + break; + if sw[0:2] in ['61', '9f']: + # A status word of 61xx or 9fxx indicates that there is (still) response data available. We + # send a GET RESPONSE command with the length value indicated in the second byte of the status + # word. (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4a and 3GPP TS 51.011 9.4.1 and + # ISO/IEC 7816-4, Table 5) + le_gr = sw[2:4] + elif sw[0:2] in ['62', '63'] or sw[0] == '9': + # There are corner cases (status word is 62xx, 63xx or 9xxx) where the UICC/eUICC/SIM asks us + # to send a dummy GET RESPONSE command. We send a GET RESPONSE command with a length of 0. + # (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4b and ETSI TS 151 011, section 9.4.1) + le_gr = '00' + else: + # A status word other then the ones covered by the above logic may indicate an error. In this + # case we will discontinue the processessing as well. + # (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4c) + break + tpdu_gr = tpdu[0:2] + 'c00000' + le_gr + prev_tpdu = tpdu_gr + data_gr, sw = self.send_tpdu(tpdu_gr) + data += data_gr if sw[0:2] == '6c': # SW1=6C: ETSI TS 102 221 Table 7.1: Procedure byte coding tpdu_gr = prev_tpdu[0:8] + sw[2:4] -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42301?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc Gerrit-Change-Number: 42301 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de>

1 0

[S] Change in osmo-remsim[master]: bankd: Avoid osmocom logging mutex deadlock in signal handling
by fixeria 09 Mar '26

09 Mar '26

Attention is currently required from: laforge, lynxis lazus. fixeria has posted comments on this change by laforge. ( https://gerrit.osmocom.org/c/osmo-remsim/+/42300?usp=email ) Change subject: bankd: Avoid osmocom logging mutex deadlock in signal handling ...................................................................... Patch Set 1: Code-Review+1 (1 comment) Commit Message: https://gerrit.osmocom.org/c/osmo-remsim/+/42300/comment/5048c49c_597185de?… : PS1, Line 13: the following stack trace the stack trace is missing? -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42300?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I5ea32886dfaf624b4dc5ad7924941c7b904c1d36 Gerrit-Change-Number: 42300 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Comment-Date: Mon, 09 Mar 2026 12:25:32 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes

1 0

[S] Change in osmo-remsim[master]: bankd: Avoid osmocom logging mutex deadlock in signal handling
by laforge 09 Mar '26

09 Mar '26

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-remsim/+/42300?usp=email ) Change subject: bankd: Avoid osmocom logging mutex deadlock in signal handling ...................................................................... bankd: Avoid osmocom logging mutex deadlock in signal handling The main thread communicates slotmap add + delete via POSIX signals to the worker threads. As those signals interrupt the normal processing of the worker thread, they might get delivered while the thread is already logging something, causing a deadlock. This has been observed in the real world in the following stack trace (where it's actually two nested signals): As a hot-fix, let's avoid logging from the handle_sig_map{del,add}() functions at all, making them safe against a deadlock around this mutex. We should decide how to proceed in general with potentially some architectural changes later on; any such changes are not suitable as a hot fix due to their potential of introducing other regressions. Change-Id: I5ea32886dfaf624b4dc5ad7924941c7b904c1d36 Related: SYS#7930 --- M src/bankd/bankd_main.c 1 file changed, 12 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/00/42300/1 diff --git a/src/bankd/bankd_main.c b/src/bankd/bankd_main.c index 1adc34c..5e33b41 100644 --- a/src/bankd/bankd_main.c +++ b/src/bankd/bankd_main.c @@ -521,9 +521,10 @@ static int worker_send_rspro(struct bankd_worker *worker, RsproPDU_t *pdu); -static void worker_set_state(struct bankd_worker *worker, enum bankd_worker_state new_state) +static void worker_set_state(struct bankd_worker *worker, enum bankd_worker_state new_state, bool quiet) { - LOGW(worker, "Changing state to %s\n", get_value_string(worker_state_names, new_state)); + if (!quiet) + LOGW(worker, "Changing state to %s\n", get_value_string(worker_state_names, new_state)); worker->state = new_state; worker->timeout = 0; } @@ -540,25 +541,26 @@ /* signal handler for receiving SIGMAPDEL from main thread */ static void handle_sig_mapdel(int sig) { - LOGW(g_worker, "SIGMAPDEL received: Main thread informs us our map is gone\n"); + /* DO NOT LOG ANYTHING HERE, IT WILL DEADLOCK WITH THE osmo_log_tgt_mutex */ OSMO_ASSERT(sig == SIGMAPDEL); if (g_worker->state >= BW_ST_CONN_CLIENT_MAPPED) { g_worker->slot.bank_id = 0xffff; g_worker->slot.slot_nr = 0xffff; - worker_set_state(g_worker, BW_ST_CONN_CLIENT_UNMAPPED); + worker_set_state(g_worker, BW_ST_CONN_CLIENT_UNMAPPED, true); } } /* signal handler for receiving SIGMAPADD from main thread */ static void handle_sig_mapadd(int sig) { - LOGW(g_worker, "SIGMAPADD received\n"); + /* DO NOT LOG ANYTHING HERE, IT WILL DEADLOCK WITH THE osmo_log_tgt_mutex */ /* do nothing */ } static void handle_sig_usr1(int sig) { OSMO_ASSERT(sig == SIGUSR1); + /* FIXME: WE SHOULD NOT LOG ANYTHING HERE, IT WILL DEADLOCK WITH THE osmo_log_tgt_mutex */ if (pthread_equal(g_bankd->main, pthread_self())) { struct bankd_worker *worker; @@ -612,7 +614,7 @@ if (rc < 0) return rc; - worker_set_state(worker, BW_ST_CONN_CLIENT_MAPPED_CARD); + worker_set_state(worker, BW_ST_CONN_CLIENT_MAPPED_CARD, false); /* FIXME: notify client about this state change */ return 0; @@ -763,7 +765,7 @@ } worker->client.clslot.client_id = pdu->msg.choice.connectClientReq.clientSlot->clientId; worker->client.clslot.slot_nr = pdu->msg.choice.connectClientReq.clientSlot->slotNr; - worker_set_state(worker, BW_ST_CONN_CLIENT); + worker_set_state(worker, BW_ST_CONN_CLIENT, false); if (worker_try_slotmap(worker) >= 0) res = ResultCode_ok; @@ -1041,7 +1043,7 @@ g_worker = (struct bankd_worker *) arg; - worker_set_state(g_worker, BW_ST_INIT); + worker_set_state(g_worker, BW_ST_INIT, false); /* not permitted in multithreaded environment */ talloc_disable_null_tracking(); @@ -1065,7 +1067,7 @@ g_worker->client.peer_addr_len = sizeof(g_worker->client.peer_addr); - worker_set_state(g_worker, BW_ST_ACCEPTING); + worker_set_state(g_worker, BW_ST_ACCEPTING, false); /* first wait for an incoming TCP connection */ rc = accept(g_worker->bankd->accept_fd, (struct sockaddr *) &g_worker->client.peer_addr, &g_worker->client.peer_addr_len); @@ -1075,7 +1077,7 @@ g_worker->client.fd = rc; worker_client_addrstr(buf, sizeof(buf), g_worker); LOGW(g_worker, "Accepted connection from %s\n", buf); - worker_set_state(g_worker, BW_ST_CONN_WAIT_ID); + worker_set_state(g_worker, BW_ST_CONN_WAIT_ID, false); /* run the main worker transceive loop body until there was some error */ while (1) { -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42300?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I5ea32886dfaf624b4dc5ad7924941c7b904c1d36 Gerrit-Change-Number: 42300 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org>

1 0

[S] Change in ...osmo-s1gw[master]: enb_registry: call enb_metrics_register/1 from a proper place
by fixeria 09 Mar '26

09 Mar '26

Attention is currently required from: laforge. fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42295?usp=email ) Change subject: enb_registry: call enb_metrics_register/1 from a proper place ...................................................................... Patch Set 2: (1 comment) Patchset: PS1: > Would have been interesting to read why the old one was improper Explained in the commit message. -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42295?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I38237463aa9c968f89bf4f195407a18cba7e73c9 Gerrit-Change-Number: 42295 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Mon, 09 Mar 2026 10:42:39 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[S] Change in ...osmo-s1gw[master]: enb_registry: call enb_metrics_register/1 from a proper place
by fixeria 09 Mar '26

09 Mar '26

Attention is currently required from: fixeria, laforge. Hello Jenkins Builder, laforge, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42295?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Code-Review+1 by laforge Change subject: enb_registry: call enb_metrics_register/1 from a proper place ...................................................................... enb_registry: call enb_metrics_register/1 from a proper place enb_metrics_register/1 requires the Global-eNB-ID to register per-eNB metrics. Calling it for every event, which may or may not contain the Global-eNB-ID, is suboptimal. Instead, invoke it from the enb_handle_event/2 clause that handles the {s1setup, GENBId} event, where the Global-Enb-ID is guaranteed to be available. Change-Id: I38237463aa9c968f89bf4f195407a18cba7e73c9 --- M src/enb_registry.erl 1 file changed, 6 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/95/42295/2 -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42295?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I38237463aa9c968f89bf4f195407a18cba7e73c9 Gerrit-Change-Number: 42295 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>

1 0

2026

2025

2024

2023

2022

gerrit-log