Attention is currently required from: laforge.
jolly has posted comments on this change by jolly. ( https://gerrit.osmocom.org/c/libosmocore/+/40855?usp=email )
Change subject: Remove old empty io_uring
......................................................................
Patch Set 5:
(1 comment)
File src/core/osmo_io_uring.c:
https://gerrit.osmocom.org/c/libosmocore/+/40855/comment/70a204aa_b2e6e129?… :
PS5, Line 620: sqe = io_uring_get_sqe_and_count(g_ring);
Wrong ring here and down below.
I am running TTCN3 tests. Fix will follow.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/40855?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id2d2a0400ad442198c684ea0ead4eaeaead4c53d
Gerrit-Change-Number: 40855
Gerrit-PatchSet: 5
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Fri, 22 Aug 2025 08:31:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Attention is currently required from: fixeria, jolly, laforge, pespin.
falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email )
Change subject: bring twjit into libosmo-netif
......................................................................
Patch Set 5:
(1 comment)
File src/twjit.c:
https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/8c26cfc3_e006745… :
PS2, Line 504: rtph = osmo_rtp_get_hdr(msg);
> I wouldn't mind getting rid of ortp and switching to something else. […]
Regarding the question of what to do in OsmoBTS, I really prefer to tackle that question *after* the present addition of twrtp to libosmo-netif is merged, not before. The present concern of extending libosmo-netif should be independent of what we ultimately decide to do in OsmoBTS.
Now back to the original thread question of adding support for M bit in twjit: I am now ready to work on this task, and I have an additional question to @pespin@sysmocom.de. My current idea is to add the optional check of M bit to `check_input_for_subbuf()` function - I hope you'll agree it seems like the best place. The question is: should this M bit check go before or after the currently implemented `if (ts_delta < 0)` check? Consider this scenario: a packet comes in M bit set, but the timestamp is in the past relative to `head_ts`. Should the past timestamp take precedence (discard the packet as too old), or should the M bit take precedence and invoke reset in HUNT or handover in FLOWING? You might wish to consider scenarios in which marker and non-marker packets get reordered by the IP network, if such reordering is possible in those worlds where you say M bit handling is needed.
From my PoV, I treat this M bit handling as a customer-requested feature, and you are the customer-like requestor - hence I need you to tell me exactly how you want it to work.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmo-netif
Gerrit-Branch: master
Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658
Gerrit-Change-Number: 39280
Gerrit-PatchSet: 5
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 21 Aug 2025 22:17:10 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: falconia <falcon(a)freecalypso.org>
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: lynxis lazus, pespin.
neels has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-msc/+/38490?usp=email )
Change subject: vlr: add PS support
......................................................................
Patch Set 11: Code-Review+1
(2 comments)
File src/libvlr/vlr_lu_fsm.c:
https://gerrit.osmocom.org/c/osmo-msc/+/38490/comment/e1e4ace2_3f96afae?usp… :
PS5, Line 771: /*! count times timer T timed out */
> i will veto block this patch unless you make this: […]
Done
https://gerrit.osmocom.org/c/osmo-msc/+/38490/comment/ad13d0c6_28e46fc5?usp… :
PS5, Line 1611: fi->T
> (Nearly) All of the timers used in the VLR are different between CS and PS. […]
yes but my point is:
any program using a VLR is only CS or PS, never both CS *and* PS. So I would expect that a PS program simply uses the PS timers, and does not need to also pass the CS timers as argument all the time, because, the entire program does never need CS timer values. Right?
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/38490?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ie9ffeb140c9d354b3a0f4822e2619f623235add0
Gerrit-Change-Number: 38490
Gerrit-PatchSet: 11
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: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Thu, 21 Aug 2025 21:51:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: lynxis lazus <lynxis(a)fe80.eu>
Attention is currently required from: lynxis lazus.
neels has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-msc/+/40422?usp=email )
Change subject: vlr: remove old TODO to switch to osmo_tdef_fsm_inst_state_chg
......................................................................
Patch Set 2: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/40422?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I1eecfeec494a2e129c41a6e964c56ed4430611de
Gerrit-Change-Number: 40422
Gerrit-PatchSet: 2
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Thu, 21 Aug 2025 21:46:51 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Attention is currently required from: lynxis lazus.
neels has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-msc/+/38491?usp=email )
Change subject: vlr_lu_fsm: terminate the FSM instead of dispatching only a signal to the parent
......................................................................
Patch Set 11: Code-Review+1
(1 comment)
File tests/msc_vlr/msc_vlr_test_authen_reuse.err:
https://gerrit.osmocom.org/c/osmo-msc/+/38491/comment/fed842f8_7e5c0267?usp… :
PS11, Line 184: DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:TMSI-0x03020100:GERAN-A:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with msc_a(IMSI-901700000010650:MSISDN-42342:TMSI-0x03020100:GERAN-A:LU)
I see here that we deallocate the msc_a much much earlier.
I am not sure about the details anymore, but there was a lot of trouble with instances deallocating, but dependent objects still accessing them for cleanup -- or dependent objects being talloc children and already disappearing before they can cleanup. Such tedious crap...
This "Deferring" is a sign that there was such trouble and the fix was to deallocate the msc_a later.
Now, there has been a general fix in osmocom for such problems, which is that we don't deallocate, but move to OTC_SELECT. It is quite possible that this patch finally gets rid of the old deferring that was necessary before we had OTC_SELECT?
I am writing this comment because, I expect that it's fine, but can you somehow check if it really is fine, please? If we use OTC_SELECT where it says "Deallocated" above on line 166 then we are fine...
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/38491?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I27fd1048f85363797b43808d2061ce28be6da81b
Gerrit-Change-Number: 38491
Gerrit-PatchSet: 11
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: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Thu, 21 Aug 2025 21:46:25 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Attention is currently required from: lynxis lazus.
neels has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-msc/+/38489?usp=email )
Change subject: vlr: when receiving imsi detach, purge the subscriber towards HLR
......................................................................
Patch Set 9: Code-Review+2
(2 comments)
File tests/msc_vlr/msc_vlr_test_ms_timeout.err:
https://gerrit.osmocom.org/c/osmo-msc/+/38489/comment/57b1089e_fc773422?usp… :
PS9, Line 668: GSUP --> HLR: OSMO_GSUP_MSGT_PURGE_MS_REQUEST: 0c010809710000004026f02801020a0101
^ This change looks different. All the others directly follow an IMSI_DETACH. Here, there is an IMSI DETACH, but it's way up there at line 644...
edit: it's fine. In this test, there is just also a pending Paging and a pending SMS being canceled in-between the IMSI DETACH rx and notifying the HLR.
File tests/msc_vlr/msc_vlr_test_no_authen.err:
https://gerrit.osmocom.org/c/osmo-msc/+/38489/comment/f62c6fe2_70381d0b?usp… :
PS9, Line 3020: GSUP --> HLR: OSMO_GSUP_MSGT_PURGE_MS_REQUEST: 0c010809710000004026f02801020a0101
This also looks different from the others; because it shows the case when a subscriber fails to do a periodic LU in time.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/38489?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I9c2569c45e69b422ce26050b682e6eb26c1c2625
Gerrit-Change-Number: 38489
Gerrit-PatchSet: 9
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Thu, 21 Aug 2025 21:34:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes