pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/33575 )
Change subject: gprs_ms: Update assert condition
......................................................................
gprs_ms: Update assert condition
A recent commit adding TBF_ST_WAIT_REUSE_TFI state updated
ms_append_llc_dl_data() to attempt creating a new DL TBF while in that
state, but forgot to update the assert checking for the conditions in
ms_is_reachable_for_dl_ass().
Related: OS#6084
Fixes: 40a297f3b0c8e1670d46a4974750dd3335bc7885
Change-Id: I3d51e909c9a9f688b7f4425a5ba319d183c71d1f
---
M src/gprs_ms.c
1 file changed, 21 insertions(+), 2 deletions(-)
Approvals:
fixeria: Looks good to me, but someone else must approve
osmith: Looks good to me, but someone else must approve
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/src/gprs_ms.c b/src/gprs_ms.c
index 5890d31..7fa3fc0 100644
--- a/src/gprs_ms.c
+++ b/src/gprs_ms.c
@@ -1093,10 +1093,13 @@
/* Can we get to send a DL TBF ass to the MS? */
static bool ms_is_reachable_for_dl_ass(const struct GprsMs *ms)
{
+ const struct gprs_rlcmac_dl_tbf *dl_tbf = ms_dl_tbf(ms);
const struct gprs_rlcmac_ul_tbf *ul_tbf = ms_ul_tbf(ms);
- /* This function assumes it is called when no DL TBF is present */
- OSMO_ASSERT(!ms_dl_tbf(ms));
+ /* This function assumes it is called when no DL TBF is present, or
+ * alternatively if it's not really in use by the MS (TBF_ST_WAIT_REUSE_TFI) */
+ OSMO_ASSERT(!dl_tbf ||
+ tbf_state(dl_tbf_as_tbf_const(dl_tbf)) == TBF_ST_WAIT_REUSE_TFI);
/* 3GPP TS 44.060 sec 7.1.3.1 Initiation of the Packet resource request procedure:
* "Furthermore, the mobile station shall not respond to PACKET DOWNLINK ASSIGNMENT
--
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/33575
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I3d51e909c9a9f688b7f4425a5ba319d183c71d1f
Gerrit-Change-Number: 33575
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: jolly.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/33515 )
Change subject: ASCI: Receive messages from MSC-A role related to VGCS/VBS
......................................................................
Patch Set 12: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/33515
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ie68eedb8fcb064a55cd71b58630d7a8c8b5f29ad
Gerrit-Change-Number: 33515
Gerrit-PatchSet: 12
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Comment-Date: Wed, 05 Jul 2023 13:40:27 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: jolly.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/33512 )
Change subject: ASCI: Add VTY to configure GCR (Group Call Register)
......................................................................
Patch Set 12:
(3 comments)
File src/libmsc/asci_vty.c:
https://gerrit.osmocom.org/c/osmo-msc/+/33512/comment/aa36a2b0_914b9692
PS10, Line 38: DEFUN(vgcs_call, vgcs_call_cmd,
> This is used to initiate a voice group call from the VTY. […]
Done
https://gerrit.osmocom.org/c/osmo-msc/+/33512/comment/55d175ba_6c2fdb5c
PS10, Line 219: "mute-talker", "Mute talker's downlink")
> This is not a dispatcher function. Unmuting talker is used for testing a call with a single phone. […]
if it's only for testing then it probably should be HIDDEN and maybe also not saved in the config file?
https://gerrit.osmocom.org/c/osmo-msc/+/33512/comment/ce900301_0e7429cc
PS10, Line 261: "no cell POINT_CODE [<0-65535>]", NO_STR "Remove BSS/cell from current group\n" PC_ID_STR)
> It is default 3.8.8 format. I changed the description accordingly.
as all our libosmo-sigtran code has user-configurable point code format, I think the same point code format should be used here. Otherwise it's inconsistent to the user. The user doesn't know whihc part of the config is parsed by a library or the application. He'd just be presented with s ome config lines that use his specified format, while others require a hard-coded format.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/33512
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I5bd034a62fc8b483f550d29103c2f7587198f590
Gerrit-Change-Number: 33512
Gerrit-PatchSet: 12
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Comment-Date: Wed, 05 Jul 2023 13:39:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: jolly <andreas(a)eversberg.eu>
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: jolly.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/33511 )
Change subject: ASCI: Add call control for VGCS/VBS
......................................................................
Patch Set 10:
(15 comments)
File src/libmsc/vgcs_fsm.c:
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5f7b6d12_9b45ad97
PS10, Line 123: tatic __attribute__((constructor)) void vgcs_bcc_fsm_init(void)
: {
: OSMO_ASSERT(osmo_fsm_register(&vgcs_bcc_fsm) == 0);
: }
:
: static __attribute__((constructor)) void vgcs_gcc_fsm_init(void)
: {
: OSMO_ASSERT(osmo_fsm_register(&vgcs_gcc_fsm) == 0);
: }
:
: static __attribute__((constructor)) void vgcs_bss_fsm_init(void)
: {
: OSMO_ASSERT(osmo_fsm_register(&vgcs_bss_fsm) == 0);
: }
:
: static __attribute__((constructor)) void vgcs_cell_fsm_init(void)
: {
: OSMO_ASSERT(osmo_fsm_register(&vgcs_cell_fsm) == 0);
: }
:
: static __attribute__((constructor)) void vgcs_mgw_ep_fsm_init(void)
: {
: OSMO_ASSERT(osmo_fsm_register(&vgcs_mgw_ep_fsm) == 0);
: }
is there a reason to have separate constructor symbols for this? Why not have one consturctor function which has N OSMO_ASSERT statements?
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5676916c_34b24ae6
PS10, Line 152: sprintf(string, "%08u", callref);
yes, 8 decimal digits plus zero termination is shorter than 16 characters, but I'd say as a matter of good practice we should still use snprintf. This makes it easier for somebody else to to audit the code, where every sprintf requires auditing if it's really ok, with snprintf you can just ignore it from manual audit/inspection.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/f5c4c9e6_54602382
PS10, Line 222: if (with_prio)
also here I would first build the 32bit value as a stack variable of uint32_t type and use msgb_put_u32() to avoid having to type-cast around and using the third byte of an uint32....
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/96efd94e_f92b21a9
PS10, Line 232: int _ie_invalid(void)
are those (_add_cause_ie, _add_callref_ie, _msg_too_short, _ie_invalid) really intended to be exported (non-static) functions? IF yes, then their name should be expanded to reflect they relate to ASCI as the name is very geneirc. If not, then they should be static.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/436e05d4_dca1bc9d
PS10, Line 249: e = msgb_put(msg, 1)
you can first buld the uint8_t as a local variable and then use msgb_put_u8(msg, value), avoiding a pointer to an array and indexing only the 0th element in it.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/48de5e4a_926d7567
PS10, Line 265: #if
not sure why this is commented out? because there are no users yet and it's a static function? IF there is a good reason to do it like this, then add a comment as explanation, please.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/4915c3cf_455819db
PS10, Line 314: payload_len
as you're decrmenting this variable, I thing I'd call it remaining_len or remaining_payload_len or something like that. payload_len sounds like the total length of the payloda field
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/1d80b9d4_bcf8d0f6
PS10, Line 323: [0] + 1;
I don't have an immediate better solution, but I really think ti is very hard to read/follow and particularly had to say if it is correct, contains some overflows, ....
You're basically incrementing the ie pointer as you go, but also deducting the payload_len pointer, both by the same amount, causing duplicate sub-expressions like "ie[0] + 1" which all must be consistent.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/7c636d95_5af9fece
PS10, Line 337: ie[0] +
here I think you're trusting ie[0] blindly, without having done much checking on it? probably osmo_mobile_identity_decode() imlpicitly trusts it as it is used as input variable.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/33b80962_fc054624
PS10, Line 346: ie += 4;
in each of those blocks we have a magic value (length) that is used three times and which must be consistent. 4 here in this example. I think there must be a way without all those copies of the same value. Like some kind of helper functions, or in the worst case macros?
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/a6d317a3_034b52be
PS10, Line 391: ie[0] = (da << 3)
again I'd put the value together in a uint8_t local variable and then msgb_put_u8() it aftrewards. This way we're not de-refernecing the zero'th element in an aray of 1, which makes it harder to read (and one might assume the array might have more elements, ...
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5c2a76a1_90ecbadf
PS10, Line 416: if (ie[3] & 0x10) {
same comments as other decoders above.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/475f3568_92b349ae
PS10, Line 604: osmo_fsm_inst_free(mgw->fi);
we typically use the goto err_* label construct here to not have to repeat all the various free functions in every case.
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/e7774254_19940618
PS10, Line 694: return -EINVAL;
here we return -EINVAL without talloc_free etc?
https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/6dbde9df_e5b6777e
PS10, Line 1279: int gsm44068_rcv_bcc_gcc(struct msc_a *msc_a, struct gsm_trans *trans, struct msgb *msg)
this function is quite long. Even the variable list alone fills half a page on soem screen heights. That's usually a sign that it should be pslit up into sub-functions.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/33511
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I9947403fde8212b66758104443c60aaacc8b1e7b
Gerrit-Change-Number: 33511
Gerrit-PatchSet: 10
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Comment-Date: Wed, 05 Jul 2023 13:36:36 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment