fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42106?usp=email )
Change subject: msc: f_tc_ho_inter_bsc0(): catch BSSMAP HandoverRequiredReject
......................................................................
msc: f_tc_ho_inter_bsc0(): catch BSSMAP HandoverRequiredReject
It may happen that the target BSC is not yet connected to the MSC.
In this case the MSC rejects handover with HandoverRequiredReject.
Let's catch this PDU to make the verdict cleaner in such case.
Change-Id: I5ba98e323e0c7794554ccb115d7697ad03ccbfa5
---
M msc/MSC_Tests.ttcn
1 file changed, 12 insertions(+), 5 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/06/42106/1
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index 5464355..17fac68 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -6043,12 +6043,19 @@
/* Now the action goes on in f_tc_ho_inter_bsc1() */
/* MSC forwards the RR Handover Command to old BSS */
- var PDU_BSSAP ho_command;
- RAN_CONN.receive(tr_BSSMAP_HandoverCommand) -> value ho_command;
+ var PDU_BSSAP pdu_bssap;
+ alt {
+ [] RAN_CONN.receive(tr_BSSMAP_HandoverCommand) -> value pdu_bssap {
+ log("Rx HandoverCommand: ", pdu_bssap);
+ RAN_CONN.receive(tr_BSSMAP_HandoverSucceeded) -> value pdu_bssap;
+ log("Rx HandoverSucceeded: ", pdu_bssap);
+ }
+ [] RAN_CONN.receive(tr_BSSMAP_HandoverRequiredReject) -> value pdu_bssap {
+ setverdict(fail, "Rx HandoverRequiredReject: ", pdu_bssap);
+ Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
+ }
+ }
- log("GOT HandoverCommand", ho_command);
-
- RAN_CONN.receive(tr_BSSMAP_HandoverSucceeded);
/* f_tc_ho_inter_bsc1() completes Handover, then expecting a Clear here. */
f_expect_clear();
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42106?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I5ba98e323e0c7794554ccb115d7697ad03ccbfa5
Gerrit-Change-Number: 42106
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: daniel, fixeria, laforge, osmith.
pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?usp=email )
Change subject: Introduce struct osmo_ss7_as_asp_assoc
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> We are usually talking about a handful of ASPs here, up to 16 if comparing to previous setups, so it […]
The only place where we may see real benefit on optimizing the llist is probably the override traffic mode, where it may make sense to keep a pointer to the currently active ASP, in order to avoid potentially traversing the whole list.
In roundrobin/loadshare traffic modes, one would expect most if not all of the ASPs in the AS be active, which means we are mostly if not always just simply picking the next item in the list from previous state.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?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: I149ab467899633ac50cba3e482b2cae02124279d
Gerrit-Change-Number: 42105
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Feb 2026 10:20:07 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: daniel, fixeria, laforge, osmith.
pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?usp=email )
Change subject: Introduce struct osmo_ss7_as_asp_assoc
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> Sadly I'm not super excited about having a linear list iteration everywehre where so far we simply h […]
We are usually talking about a handful of ASPs here, up to 16 if comparing to previous setups, so it's not like we are talking about iterating super long lists.
Talking about userplane traffic forwarding, we focus on selecting an ASP given an AS, depending on traffic mode:
* loadshare: not really affected in hot path, only when deciding to select/change a given normal/alternative destination in the binding table due to it changing status.
* roundrobin: ss7_as_select_asp_roundrobin() In general it will simply pick the next in the list, number of jumps depend on how many active we have. As mentioned this can be optimized later by having an extra "asp_active_list".
* override: ss7_as_select_asp_override(), this may be the only one which may want to traverse most of the llist in certain conditions. As mentioned this can be optimized later by having an extra "asp_active_list", or by moving an ASP fist in the llist when it is activated.
* broadcast: Not sure somebody really wants to use broadcast with a big amount of ASPs anyway...
Moreover, most of those loops are not really tight loops, since they are calling functions for each asp, etc.
BTW, fyi, we are already using llists in the previous step when
selecting an AS from the combined linkset, which always happens in
loadshare mode.
This is a first implementation to at least support more ASPs. We can always later on optimize the bottlenecks adding separate llists for eg. active ASPs, adding hashtables to look up for ASP in an AS, etc.
In any case, it doesn't make sense imho to try to accomplish all of that in the same first commit, the changes are big/complex enough as of current change. I still plan to submit more follow-up patches wrt this topic.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?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: I149ab467899633ac50cba3e482b2cae02124279d
Gerrit-Change-Number: 42105
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Feb 2026 10:16:24 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Attention is currently required from: canghaiwuhen.
pespin has posted comments on this change by canghaiwuhen. ( https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email )
Change subject: Some older modules, such as the Air20X module, may crash during PDP attachment due to excessively long QoS response packets. If the PDP is not released after successful attachment, the module will restart, and subsequent TCP connections will fail.
......................................................................
Patch Set 5: Code-Review-1
(5 comments)
Commit Message:
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/d9e10470_b75e3806?us… :
PS5, Line 7: Some older modules, such as the Air20X module, may crash during PDP attachment due to excessively long QoS response packets.
Missing first line with acceptable length. You are writing the whole description in the first line.
File src/sgsn/gprs_gmm.c:
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/d3c84754_616b1cfb?us… :
PS5, Line 1339: } else {
All changes in this file are totally unrelated to those of QoS.
Submit a separate patch for individual code review.
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/11c5685c_367d7d8e?us… :
PS5, Line 1340: /* [FIX] Known IMSI context. If the module initiates an Attach, it means it has restarted and lost its PDP state.
These lines are too long, split them.
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/9b0a1e3c_727925de?us… :
PS5, Line 1344: LOGMMCTXP(LOGL_NOTICE, ctx, "Re-Attach: Dropping stale PDP context for NSAPI=%u\n", pdp->nsapi);
Line too long.
File src/sgsn/gprs_sm.c:
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/044b6397_a6aed6de?us… :
PS5, Line 209: //msgb_lv_put(msg, sizeof(default_qos), (uint8_t *)&default_qos);
This line can be removed, since you are replacing it.
--
To view, visit https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-sgsn
Gerrit-Branch: master
Gerrit-Change-Id: I11c24b64f0e49cf80c825969dbf018b2948d855c
Gerrit-Change-Number: 42050
Gerrit-PatchSet: 5
Gerrit-Owner: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Comment-Date: Wed, 11 Feb 2026 09:57:57 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Attention is currently required from: canghaiwuhen.
laforge has posted comments on this change by canghaiwuhen. ( https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email )
Change subject: Some older modules, such as the Air20X module, may crash during PDP attachment due to excessively long QoS response packets. If the PDP is not released after successful attachment, the module will restart, and subsequent TCP connections will fail.
......................................................................
Patch Set 5: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-sgsn
Gerrit-Branch: master
Gerrit-Change-Id: I11c24b64f0e49cf80c825969dbf018b2948d855c
Gerrit-Change-Number: 42050
Gerrit-PatchSet: 5
Gerrit-Owner: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Comment-Date: Wed, 11 Feb 2026 09:21:23 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Attention is currently required from: daniel, fixeria, osmith, pespin.
laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?usp=email )
Change subject: Introduce struct osmo_ss7_as_asp_assoc
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
Sadly I'm not super excited about having a linear list iteration everywehre where so far we simply had an array-index access. The STP may see a rather high rate of messages per second (MSU rate), and anything that slows down the hot path traversed by every message should be as efficient as possible. Ideally any change would make it more efficient, than less so.
I might be overly conservative/cautious here, but I'm wondering if we cannot find something more efficient, like a dynamically-sized+reallocated array. After all, the number of ASPs change relatively infrequently compared to the number of MSU we process over time. So making the ASP add/remove more expensive is fine, if the hot path per message has no penalty.
It might also be worth doing a simple benchmark to see the actual performance impact vs. my thoughts/expectations here.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?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: I149ab467899633ac50cba3e482b2cae02124279d
Gerrit-Change-Number: 42105
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Feb 2026 09:17:28 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
laforge has submitted this change. ( https://gerrit.osmocom.org/c/pysim/+/42009?usp=email )
(
1 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
)Change subject: compile_asn1_subdir: filter compiled files by .asn suffix
......................................................................
compile_asn1_subdir: filter compiled files by .asn suffix
When I open the .asn file in vim, pySim should not attempt to read the
vim .swp file as asn.1.
File "/home/moi/osmo-dev/src/pysim/pySim/esim/saip/__init__.py", line 45, in <module>
asn1 = compile_asn1_subdir('saip')
[...]
File "<frozen codecs>", line 325, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xad in position 21: invalid start byte
Related: OS#6937
Change-Id: I37df3fc081e51e2ed2198876c63f6e68ecc8fcd8
---
M pySim/esim/__init__.py
1 file changed, 2 insertions(+), 0 deletions(-)
Approvals:
fixeria: Looks good to me, approved
Jenkins Builder: Verified
laforge: Looks good to me, but someone else must approve
diff --git a/pySim/esim/__init__.py b/pySim/esim/__init__.py
index 35b733e..9bbaf17 100644
--- a/pySim/esim/__init__.py
+++ b/pySim/esim/__init__.py
@@ -54,6 +54,8 @@
__ver = sys.version_info
if (__ver.major, __ver.minor) >= (3, 9):
for i in resources.files('pySim.esim').joinpath('asn1').joinpath(subdir_name).iterdir():
+ if not i.name.endswith('.asn'):
+ continue
asn_txt += i.read_text()
asn_txt += "\n"
#else:
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/42009?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: merged
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I37df3fc081e51e2ed2198876c63f6e68ecc8fcd8
Gerrit-Change-Number: 42009
Gerrit-PatchSet: 3
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Attention is currently required from: canghaiwuhen.
Jenkins Builder has posted comments on this change by canghaiwuhen. ( https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email )
Change subject: Some older modules, such as the Air20X module, may crash during PDP attachment due to excessively long QoS response packets. If the PDP is not released after successful attachment, the module will restart, and subsequent TCP connections will fail.
......................................................................
Patch Set 4:
(6 comments)
File src/sgsn/gprs_gmm.c:
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/c55ee09f_d7da6f88?us… :
PS4, Line 1340: /* [FIX] Known IMSI context. If the module initiates an Attach, it means it has restarted and lost its PDP state.
trailing whitespace
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/4154947e_40a46358?us… :
PS4, Line 1341: * We must clean up the old PDP context on the SGSN side; otherwise, the SGSN will not recreate them, leading to communication failure. */
code indent should use tabs where possible
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/7d7e51b4_649bd5f0?us… :
PS4, Line 1341: * We must clean up the old PDP context on the SGSN side; otherwise, the SGSN will not recreate them, leading to communication failure. */
please, no space before tabs
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/ee3726d4_736165b3?us… :
PS4, Line 1368: llist_for_each_entry_safe(pdp, pdp2, &ctx->pdp_list, list) {
suspect code indent for conditional statements (24, 24)
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/1cb547cf_b4b79eb3?us… :
PS4, Line 1372: }
code indent should use tabs where possible
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/osmo-sgsn/+/42050/comment/1e516135_bbd620dc?us… :
PS4, Line 1372: }
please, no spaces at the start of a line
--
To view, visit https://gerrit.osmocom.org/c/osmo-sgsn/+/42050?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-sgsn
Gerrit-Branch: master
Gerrit-Change-Id: I11c24b64f0e49cf80c825969dbf018b2948d855c
Gerrit-Change-Number: 42050
Gerrit-PatchSet: 4
Gerrit-Owner: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: canghaiwuhen <canghaiwuhen(a)gmail.com>
Gerrit-Comment-Date: Tue, 10 Feb 2026 15:41:39 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No