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

[M] Change in osmo-ttcn3-hacks[master]: 5gc: Introduce test TC_pdu_sess_est_always_on
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: pespin. fixeria has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42478?usp=email ) Change subject: 5gc: Introduce test TC_pdu_sess_est_always_on ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42478?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: I282e0c8072172fa633bf82ed6b9492b0bb4362cc Gerrit-Change-Number: 42478 Gerrit-PatchSet: 4 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:58:18 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[S] Change in osmo-ttcn3-hacks[master]: library/PFCP_Emulation: add f_PFCPEM_set_recovery_timestamp()
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: pespin. fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42492?usp=email ) Change subject: library/PFCP_Emulation: add f_PFCPEM_set_recovery_timestamp() ...................................................................... Patch Set 1: (1 comment) Commit Message: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42492/comment/22e5c9ec_32db… : PS1, Line 12: peer restart between test cases. > Ah ok so it's not in between tests, it's in the same test because you are spwarning a different ConnHdlr to do the Assoc Setup... Not really. All ConnHdlr connect to the same instance of PFCPEM, so this is not a problem. The association remains alive regardless of the `ConnHdlr` lifetime. Furthermore, the same association remains alive and is re-used even across multiple testcases, because osmo-s1gw currently does not send any heartbeats (patches for that are in review) and thus does not detect that the simulated UPF has been restarted. > Why would you like to avoid the IUT not detecting the restart? After all we are resetting the state in our PFCP endpoint after every test... The existing testcase init logic does so-called "lazy" association. First we query the S1GW's PFCP state via REST (previously we relied on StatsD gauge for that). If S1GW reports no association, then wait for the assoc setup request and do the association. If S1GW reports an existing association (`state == connected`), we simply do nothing a proceed with the actual testcase logic. It's fine to re-use the existing association, at least I see nothing wrong with that. The only problem here is that the local RTS of PFCPEM changes across testcases, and this will trigger S1GW to reset the existing association as soon as the RTS mismatch is detected. This is why I am adding API for changing the local RTS in PFCPEM, and the following patch makes use of it. -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42492?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: If47e06d26b42081a28aacb6e06b5aeabf945362c Gerrit-Change-Number: 42492 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:54:31 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in pysim[master]: pysim/pcsc: do not use getProtocol for protocol selection
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: dexter, laforge. fixeria has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/pysim/+/42475?usp=email ) Change subject: pysim/pcsc: do not use getProtocol for protocol selection ...................................................................... Patch Set 2: Code-Review+1 (1 comment) File pySim/transport/pcsc.py: https://gerrit.osmocom.org/c/pysim/+/42475/comment/2f24036c_27e46aef?usp=em… : PS2, Line 88: on 'on' is not needed here? -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42475?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: Ib119948aa68c430e42ac84daec8b9bd542db7963 Gerrit-Change-Number: 42475 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:20:07 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes

1 0

[XS] Change in osmo-uecups[master]: gtp_tunnel: Log Tx of ICMPv6 Router Solicitation
by pespin 25 Mar '26

25 Mar '26

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-uecups/+/42500?usp=email ) Change subject: gtp_tunnel: Log Tx of ICMPv6 Router Solicitation ...................................................................... gtp_tunnel: Log Tx of ICMPv6 Router Solicitation Change-Id: I5883a0e399e47b6e169c5adf8446e9d2aeecbe68 --- M daemon/gtp_tunnel.c 1 file changed, 4 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-uecups refs/changes/00/42500/1 diff --git a/daemon/gtp_tunnel.c b/daemon/gtp_tunnel.c index fc99e4f..c115cd4 100644 --- a/daemon/gtp_tunnel.c +++ b/daemon/gtp_tunnel.c @@ -215,8 +215,12 @@ static int _gtp_tunnel_tx_icmpv6_rs(struct gtp_tunnel *t) { struct msgb *msg; + char ipbuf[INET6_ADDRSTRLEN]; int rc; + LOGT(t, LOGL_INFO, "Tx ICMPv6 Router Solicitation for %s\n", + osmo_sockaddr_ntop(&t->user_addr_ipv6_ll.u.sa, ipbuf)); + OSMO_ASSERT(t->user_addr_type == GTP1U_EUA_TYPE_IPv6 || t->user_addr_type == GTP1U_EUA_TYPE_IPv4v6); -- To view, visit https://gerrit.osmocom.org/c/osmo-uecups/+/42500?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-uecups Gerrit-Branch: master Gerrit-Change-Id: I5883a0e399e47b6e169c5adf8446e9d2aeecbe68 Gerrit-Change-Number: 42500 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in pysim[master]: pysim/pcsc: do not use getProtocol for protocol selection
by dexter 25 Mar '26

25 Mar '26

Attention is currently required from: fixeria, laforge. dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/pysim/+/42475?usp=email ) Change subject: pysim/pcsc: do not use getProtocol for protocol selection ...................................................................... Patch Set 2: (1 comment) Patchset: PS1: > Agreed. I have now added a comment. I have also checked pyscard manual again. There is no explicit suggestion or preferred way how to do deal with the protocol selection. I think the way we do it now is perfectly valid. The API even provides a setProtocol method, which I am using now. With that we do not have to close and re-open the connection. -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42475?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: Ib119948aa68c430e42ac84daec8b9bd542db7963 Gerrit-Change-Number: 42475 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:16:10 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>

1 0

[S] Change in pysim[master]: pysim/pcsc: do not use getProtocol for protocol selection
by dexter 25 Mar '26

25 Mar '26

Attention is currently required from: fixeria, laforge. Hello Jenkins Builder, fixeria, laforge, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/pysim/+/42475?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: pysim/pcsc: do not use getProtocol for protocol selection ...................................................................... pysim/pcsc: do not use getProtocol for protocol selection The documentation of the getProtocol provided by pyscard says: "Return bit mask for the protocol of connection, or None if no protocol set. The return value is a bit mask of CardConnection.T0_protocol, CardConnection.T1_protocol, CardConnection.RAW_protocol, CardConnection.T15_protocol" This suggests that the purpose of getProtocol is not to determine which protocols are supported. Its purpose is to determine which protocol is currently selected (either through auto selection or through the explicit selection made by the API user). This means we are using getProtocol wrong. So far this was no problem, since the auto-selected protocol should be a supported protocol anyway. However, the automatic protocol selection may not always return a correct result (see bug report from THD-siegfried [1]). Let's not trust the automatic protocol selection. Instead let's parse the ATR and make the decision based on the TD1/TD2 bytes). [1] https://osmocom.org/issues/6952 Related: OS#6952 Change-Id: Ib119948aa68c430e42ac84daec8b9bd542db7963 --- M pySim/transport/pcsc.py 1 file changed, 11 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/75/42475/2 -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42475?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: Ib119948aa68c430e42ac84daec8b9bd542db7963 Gerrit-Change-Number: 42475 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>

1 0

[S] Change in osmo-ttcn3-hacks[master]: s1gw: f_ConnHdlr_pfcp_assoc_handler(): handle already-connected case
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: pespin. fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42493?usp=email ) Change subject: s1gw: f_ConnHdlr_pfcp_assoc_handler(): handle already-connected case ...................................................................... Patch Set 1: (1 comment) File s1gw/S1GW_Tests.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42493/comment/67c67863_6d9b… : PS1, Line 143: vc_conn := f_ConnHdlr_spawn(refers(f_ConnHdlr_pfcp_assoc_handler), > I wonder why do you need to spawn a new ConnHdlr to do some non-session related stuff. […] `test_CT` is not connected to the PFCPEM, so they cannot communicate. Only `ConnHdlr` components can talk to the PFCPEM. This is why I am spawning a `ConnHdlr` here. I could connect `test_CT` to the PFCPEM, but this would be the only reason to do that: we do not run test logic directly in `test_CT`. Also, a `ConnHdlr` can re-use the existing API to send and expect PFCP PDUs, so this is more convenient. -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42493?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: Id9d2ebb1ddb3d3896dd24e2a37e9d21335441d52 Gerrit-Change-Number: 42493 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:12:04 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in osmo-ttcn3-hacks[master]: s1gw: generalize f_TC_e_rab_setup_failure() for N E-RABs
by fixeria 25 Mar '26

25 Mar '26

fixeria has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42496?usp=email ) Change subject: s1gw: generalize f_TC_e_rab_setup_failure() for N E-RABs ...................................................................... s1gw: generalize f_TC_e_rab_setup_failure() for N E-RABs The existing TC only tested PFCP Session Establishment failure with a single E-RAB. Generalize f_TC_e_rab_setup_failure() to use g_pars.erabs throughout, so it works for any num_erabs: E-RAB 0 still triggers the only PFCP Session Establishment Request (S1GW processes sequentially), while all E-RABs in the request are expected to appear in the failure response. Add TC_e_rab_setup3_failure() which re-uses the same body with num_erabs := 3, verifying that the S1GW lists all three E-RABs as failed rather than just the first one. Also make f_tr_E_RABList() non-private so it is accessible from S1GW_Tests.ttcn. Change-Id: I8a5dc338d28013dc85e1ce4b3bdac92cb3b35304 Related: osmo-s1gw.git I7933fceb0edcdfdc95ace35416297b11c83f0bc9 --- M s1gw/S1GW_ConnHdlr.ttcn M s1gw/S1GW_Tests.ttcn M s1gw/expected-results.xml 3 files changed, 26 insertions(+), 20 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, approved laforge: Looks good to me, but someone else must approve diff --git a/s1gw/S1GW_ConnHdlr.ttcn b/s1gw/S1GW_ConnHdlr.ttcn index fd171d3..63e828b 100644 --- a/s1gw/S1GW_ConnHdlr.ttcn +++ b/s1gw/S1GW_ConnHdlr.ttcn @@ -886,8 +886,8 @@ return items; } -private function f_tr_E_RABList(in ERabList erabs, - S1AP_IEs.Cause cause) +function f_tr_E_RABList(in ERabList erabs, + S1AP_IEs.Cause cause) return template (present) E_RABList { var template (present) E_RABList items; diff --git a/s1gw/S1GW_Tests.ttcn b/s1gw/S1GW_Tests.ttcn index f86546c..61f2a61 100644 --- a/s1gw/S1GW_Tests.ttcn +++ b/s1gw/S1GW_Tests.ttcn @@ -493,11 +493,13 @@ f_TC_exec(refers(f_TC_e_rab_release_ind)); } -/* Test E-RAB SETUP procedure being aborted by the S1GW due to - * PFCP Session Establishment failure (cause=REQUEST_REJECTED). */ +/* Test E-RAB SETUP failure: all E-RABs in the request fail because the first + * PFCP Session Establishment is rejected. The S1GW processes E-RABs sequentially, + * so only E-RAB 0 triggers a PFCP Session Establishment Request; the remaining + * E-RABs (if any) are abandoned. The S1GW must list all E-RABs as failed. */ function f_TC_e_rab_setup_failure(charstring id) runs on ConnHdlr { var OCT4 addr := f_inet_addr(g_pars.pfcp_loc_addr); - var ERab erab := g_pars.erabs[0]; + var ERab erab0 := g_pars.erabs[0]; f_ConnHdlr_s1ap_register(g_pars.genb_id); f_ConnHdlr_s1ap_connect(mp_enb_bind_ip, mp_s1gw_enb_ip); @@ -505,46 +507,48 @@ /* see comments in f_ConnHdlr_erab_setup_req() */ f_PFCPEM_subscribe_seid('0000000000000000'O); - f_PFCPEM_subscribe_seid(erab.pfcp_loc_seid); + f_PFCPEM_subscribe_seid(erab0.pfcp_loc_seid); log("eNB <- [S1GW <- MME]: E-RAB SETUP REQUEST"); - f_ConnHdlr_tx_erab_setup_req({erab}, g_pars.mme_ue_id, g_pars.idx); - log("UPF <- S1GW: PFCP Session Establishment Request"); - var PDU_PFCP req := f_ConnHdlr_rx_session_establish_req(erab); - /* store peer's SEID, so that it can be used in outgoing PDUs later */ - erab.pfcp_rem_seid := req.message_body.pfcp_session_establishment_request.CP_F_SEID.seid; + f_ConnHdlr_tx_erab_setup_req(g_pars.erabs, g_pars.mme_ue_id, g_pars.idx); + log("UPF <- S1GW: PFCP Session Establishment Request (E-RAB 0)"); + var PDU_PFCP req := f_ConnHdlr_rx_session_establish_req(erab0); + erab0.pfcp_rem_seid := req.message_body.pfcp_session_establishment_request.CP_F_SEID.seid; log("UPF -> S1GW: PFCP Session Establishment Response (failure)"); var template (value) PDU_PFCP resp; resp := ts_PFCP_Session_Est_Resp(seq_nr := req.sequence_number, node_id := ts_PFCP_Node_ID_ipv4(addr), - seid := erab.pfcp_rem_seid, - f_seid := ts_PFCP_F_SEID_ipv4(addr, erab.pfcp_loc_seid), + seid := erab0.pfcp_rem_seid, + f_seid := ts_PFCP_F_SEID_ipv4(addr, erab0.pfcp_loc_seid), created_pdr := {}, cause := ts_PFCP_Cause(REQUEST_REJECTED)); PFCP.send(resp); /* see comments in f_ConnHdlr_erab_setup_req() */ f_PFCPEM_unsubscribe_seid('0000000000000000'O); - f_PFCPEM_unsubscribe_seid(erab.pfcp_loc_seid); + f_PFCPEM_unsubscribe_seid(erab0.pfcp_loc_seid); - /* expect E-RAB SETUP RESPONSE replied by the S1GW */ + log("eNB -- [S1GW -> MME]: E-RAB SETUP RESPONSE (all E-RABs failed)"); + var template (present) E_RABList failed_items; var template (present) S1AP_PDU setup_rsp; - var template (present) E_RABItem item; var S1AP_PDU s1ap_pdu; - log("eNB -- [S1GW -> MME]: E-RAB SETUP RESPONSE (failure)"); - item := tr_E_RABItem(erab.erab_id, {transport := transport_resource_unavailable}); + failed_items := f_tr_E_RABList(g_pars.erabs, + cause := {transport := transport_resource_unavailable}); setup_rsp := tr_S1AP_RABSetupRsp(g_pars.mme_ue_id, g_pars.idx, rab_setup_items := omit, - rab_failed_items := tr_E_RABList(item)); + rab_failed_items := failed_items); f_ConnHdlr_rx_s1ap_from_enb(s1ap_pdu, setup_rsp); f_ConnHdlr_s1ap_disconnect(); f_ConnHdlr_s1ap_unregister(g_pars.genb_id); } testcase TC_e_rab_setup_failure() runs on test_CT { - f_TC_exec(refers(f_TC_e_rab_setup_failure)); + f_TC_exec(refers(f_TC_e_rab_setup_failure), num_erabs := 1); +} +testcase TC_e_rab_setup3_failure() runs on test_CT { + f_TC_exec(refers(f_TC_e_rab_setup_failure), num_erabs := 3); } /* Test E-RAB MODIFY Req/Rsp procedure */ @@ -1374,6 +1378,7 @@ execute( TC_e_rab_setup3_multi() ); execute( TC_e_rab_release_ind() ); execute( TC_e_rab_setup_failure() ); + execute( TC_e_rab_setup3_failure() ); execute( TC_e_rab_modify_req_rsp() ); execute( TC_e_rab_modify_req_rsp_multi() ); execute( TC_e_rab_modify_ind_cnf() ); diff --git a/s1gw/expected-results.xml b/s1gw/expected-results.xml index b2b6cdb..5e1e9cb 100644 --- a/s1gw/expected-results.xml +++ b/s1gw/expected-results.xml @@ -10,6 +10,7 @@ <testcase classname='S1GW_Tests' name='TC_e_rab_setup3_multi' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_release_ind' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_setup_failure' time='MASKED'/> + <testcase classname='S1GW_Tests' name='TC_e_rab_setup3_failure' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_modify_req_rsp' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_modify_req_rsp_multi' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_modify_ind_cnf' time='MASKED'/> -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42496?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I8a5dc338d28013dc85e1ce4b3bdac92cb3b35304 Gerrit-Change-Number: 42496 Gerrit-PatchSet: 2 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: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in ...osmo-s1gw[master]: s1ap_proxy: fix build_erab_setup_response_failure() to report all E-RABs
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: pespin. fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42497?usp=email ) Change subject: s1ap_proxy: fix build_erab_setup_response_failure() to report all E-RABs ...................................................................... Patch Set 1: (1 comment) File src/s1ap_proxy.erl: https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42497/comment/87eba699_9dfd… : PS1, Line 334: value = Items} <- C0#'E-RABSetupRequest'.protocolIEs, > Can you move the "<- part to a line below so the whole block becomes clearer? […] Done. I've also added some comments. -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42497?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: I7933fceb0edcdfdc95ace35416297b11c83f0bc9 Gerrit-Change-Number: 42497 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 25 Mar 2026 13:03:09 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in ...osmo-s1gw[master]: s1ap_proxy: fix build_erab_setup_response_failure() to report all E-RABs
by fixeria 25 Mar '26

25 Mar '26

Attention is currently required from: fixeria, pespin. Hello Jenkins Builder, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42497?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Code-Review+1 by pespin, Verified+1 by Jenkins Builder Change subject: s1ap_proxy: fix build_erab_setup_response_failure() to report all E-RABs ...................................................................... s1ap_proxy: fix build_erab_setup_response_failure() to report all E-RABs The previous implementation only included the first E-RAB from the registry in the failure response (a FIXME was left in place). Fix it to extract all E-RAB IDs from the original E-RAB SETUP REQUEST and include each of them in the failure list, as required by 3GPP. Change-Id: I7933fceb0edcdfdc95ace35416297b11c83f0bc9 Related: osmo-ttcn3-hacks.git I8a5dc338d28013dc85e1ce4b3bdac92cb3b35304 --- M src/s1ap_proxy.erl 1 file changed, 15 insertions(+), 9 deletions(-) git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/97/42497/2 -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/42497?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: I7933fceb0edcdfdc95ace35416297b11c83f0bc9 Gerrit-Change-Number: 42497 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>

1 0

2026

2025

2024

2023

2022

gerrit-log March 2026