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
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42104?usp=email )
Change subject: cosmetic: ss7_asp.h: Drop comment no longer valid
......................................................................
cosmetic: ss7_asp.h: Drop comment no longer valid
Since a while ago, remote asp ID is stored in asp->remote_asp_id.
Fixes: b8fe5e4a1adfb54f265efc81432eab6252e9b04f
Change-Id: I2253b1cb9e24270b9d6b3400d3fa20827c66ad23
---
M src/ss7_asp.h
1 file changed, 0 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-sigtran refs/changes/04/42104/1
diff --git a/src/ss7_asp.h b/src/ss7_asp.h
index 459163f..80a0a8a 100644
--- a/src/ss7_asp.h
+++ b/src/ss7_asp.h
@@ -71,7 +71,6 @@
char *sock_name;
/* ASP Identifier for ASP-UP + NTFY, as received by the peer.
- * (In IPA ASPs it's used internally to hold 4-bit SLS).
* FIXME: This should actually be stored in a AS-ASP relation, since it
* can be different per AS, see RFC4666 3.5.1
* "The optional ASP Identifier parameter contains a unique value that
--
To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/42104?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: libosmo-sigtran
Gerrit-Branch: master
Gerrit-Change-Id: I2253b1cb9e24270b9d6b3400d3fa20827c66ad23
Gerrit-Change-Number: 42104
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>