Attention is currently required from: wbokslag.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-tetra/+/34001
to look at the new patch set (#3).
Change subject: Added functions that prepare for decryption functionality
......................................................................
Added functions that prepare for decryption functionality
Added functions that will eventually allow for mac resource decryption,
voice/traffic decryption and identity decryption. Calls to the true TEA
keystream generator functions and TA61 identity decryption function
will need to be added in a later patch.
Change-Id: I4e6147f206ad6046f32e08015ec9721b64382ca1
---
M src/crypto/tetra_crypto.c
M src/crypto/tetra_crypto.h
2 files changed, 131 insertions(+), 13 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-tetra refs/changes/01/34001/3
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/34001
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: I4e6147f206ad6046f32e08015ec9721b64382ca1
Gerrit-Change-Number: 34001
Gerrit-PatchSet: 3
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-MessageType: newpatchset
Attention is currently required from: laforge.
wbokslag has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/34000 )
Change subject: Fixups and clarifying comments for msgb tail modifications
......................................................................
Patch Set 2:
(2 comments)
Patchset:
PS2:
After further inspection, I find the msgb_trim function uses msgb->data as a reference, which is a problem, due to the multiple-resources-per-timeslot scenario. It would work if l1h were used as a reference, since I move that pointer forward in tetra_lower_mac.c. I'm not against refactoring all the manual field manipulation to an osmocom buffer manipulation function but can you suggest a way to do it properly?
What's the semantically correct way to deal with multiple upper mac messages in a buffer?
File src/lower_mac/tetra_lower_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/173bdf49_1109459c
PS2, Line 347: msg->len = msg
> Okay, I appreciate the comments and effort to maintain good code quality. […]
After further inspection, I find the msgb_trim function uses msgb->data as a reference, which is a problem, due to the multiple-resources-per-timeslot scenario. It would work if l1h were used as a reference, since I move that pointer forward in tetra_lower_mac.c. I'm not against refactoring all the manual field manipulation to an osmocom buffer manipulation function but can you suggest a way to do it properly?
What's the semantically correct way to deal with multiple upper mac messages in a buffer?
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/34000
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: Ia725edbeafe26bd2ea9b5a1810d0b26bc79d84db
Gerrit-Change-Number: 34000
Gerrit-PatchSet: 2
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Sat, 29 Jul 2023 10:02:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: wbokslag <w.bokslag(a)midnightblue.nl>
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: laforge.
wbokslag has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/34000 )
Change subject: Fixups and clarifying comments for msgb tail modifications
......................................................................
Patch Set 2:
(7 comments)
Patchset:
PS2:
Hi, thanks again for the extensive comments. I elaborated the issue in a reply on your comment on tetra_lower_mac, and I believe indeed trim / l3trim may be suited for use in tetra_upper_mac and the LLC code
File src/lower_mac/tetra_lower_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/c0575652_18ca0744
PS2, Line 347: msg->len = msg
> in general we don't ever manually manipulate msgb's this way in other osmocom software. […]
Okay, I appreciate the comments and effort to maintain good code quality. I am not deeply familiar with the osmocom primitives, so maybe I'm overlooking something.
The essence of the problem is this. Suppose we have a timeslot on the signalling channel, which will contain MAC-RESOURCE pdus and the like. According to the standard, multiple PDUs may be contained in a single timeslot. So the MAC layer parsing code needs to have an accurate l1h, l2h, l3h start marker for the different layers of the protocol, BUT ALSO need to know how long the payload for their respective layer is.
During parsing in tetra_upper_mac, the tail pointer is moved closer to the start, based on MAC-RESOURCE len field. Also, the tail pointer is moved closer to the start in the LLC layer (layer 2) if a 32-bit FCS is present AFTER the layer 3 MLE data. This is needed, because layer 3 parsing requires accurate start (l3h) and end/length markers.
However, once the upper mac parsing is done and we return to the lower mac, we need to parse any further resources that may be present in the timeslot. That's why I advance the head, put the tail at the end of the slot again and then fix the end field.
msgb_get seemed unsuitable for the purpose since its description states "removes data from the end", as such, I felt I have no guarantee the data there will remain intact and/or allocated. Also semantically it seems like we definitively discard this data. In your next comment you bring msgb_trim (for l2) and msgb_l3trim to my attention, that indeed looks suitable, I'll refactor.
File src/tetra_llc.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/b443b21b_ab95c3cf
PS2, Line 124: msg->tail = msg->l3h + lpp.tl_sdu_len; // Strips off FCS (if present)
: msg->len = msg->tail - msg->head;
> this looks a bit like openn-coding a msgb_get(), or probably even more a msgb_l3trim() ?
Done
File src/tetra_upper_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/9bdada54_cca44860
PS2, Line 178: msg->len = m
> same here. […]
Done
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/e5e44e08_c7971e2a
PS2, Line 185: msg->len = m
> same here. […]
Done
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/1b2939f2_78548fbe
PS2, Line 306: msg->len = m
> yet another msgb_trim? Also, the entire get_num_fill_bits + following operations happens several ti […]
Ack
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/c818c925_1fb1ed55
PS2, Line 359: msg->len = m
> again another fill-bits-stripping situation.
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/34000
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: Ia725edbeafe26bd2ea9b5a1810d0b26bc79d84db
Gerrit-Change-Number: 34000
Gerrit-PatchSet: 2
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Sat, 29 Jul 2023 09:47:12 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/pysim/+/33994 )
Change subject: README.md: Add note about pySim-trace.py dependencies
......................................................................
README.md: Add note about pySim-trace.py dependencies
Related: OS#6094
Change-Id: I2e03f9c827bd6ee73891bba34bd2f2efe3ded7e6
---
M README.md
1 file changed, 13 insertions(+), 0 deletions(-)
Approvals:
laforge: Looks good to me, approved
Jenkins Builder: Verified
diff --git a/README.md b/README.md
index 2a89c9a..c3c5a25 100644
--- a/README.md
+++ b/README.md
@@ -101,6 +101,9 @@
After installing all dependencies, the pySim applications ``pySim-read.py``, ``pySim-prog.py`` and ``pySim-shell.py`` may be started directly from the cloned repository.
+In addition to the dependencies above ``pySim-trace.py`` requires ``tshark`` and the python package ``pyshark`` to be installed. It is known that the ``tshark`` package
+in Debian versions before 11 may not work with pyshark.
+
### Archlinux Package
Archlinux users may install the package ``python-pysim-git``
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/33994
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I2e03f9c827bd6ee73891bba34bd2f2efe3ded7e6
Gerrit-Change-Number: 33994
Gerrit-PatchSet: 2
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has submitted this change. ( https://gerrit.osmocom.org/c/pysim/+/33964 )
(
2 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
)Change subject: pysim-test: rename pysim-test.sh to pySim-prog_test.sh
......................................................................
pysim-test: rename pysim-test.sh to pySim-prog_test.sh
We now have pySim-shell and pySim-trace. Let's give pysim-test.sh a more
distinctive name so that it is clear to which program it refers.
Related: OS#6094
Change-Id: I438f63f9580ebd3c7cc78cc5dab13c9937ac6e3a
---
M contrib/jenkins.sh
R tests/pySim-prog_test.sh
2 files changed, 16 insertions(+), 3 deletions(-)
Approvals:
laforge: Looks good to me, but someone else must approve
fixeria: Looks good to me, approved
Jenkins Builder: Verified
diff --git a/contrib/jenkins.sh b/contrib/jenkins.sh
index 3e02546..e75ac40 100755
--- a/contrib/jenkins.sh
+++ b/contrib/jenkins.sh
@@ -29,7 +29,7 @@
# Run the test with physical cards
cd pysim-testdata
- ../tests/pysim-test.sh
+ ../tests/pySim-prog_test.sh
../tests/pySim-trace_test.sh
;;
"pylint")
diff --git a/tests/pysim-test.sh b/tests/pySim-prog_test.sh
similarity index 97%
rename from tests/pysim-test.sh
rename to tests/pySim-prog_test.sh
index 4004c18..f248768 100755
--- a/tests/pysim-test.sh
+++ b/tests/pySim-prog_test.sh
@@ -27,8 +27,8 @@
set -e
-echo "pysim-test - a test program to test pysim-prog.py"
-echo "================================================="
+echo "pySim-prog_test - a test program to test pysim-prog.py"
+echo "======================================================"
# Generate a list of the cards we expect to see by checking which .ok files
# are present
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/33964
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I438f63f9580ebd3c7cc78cc5dab13c9937ac6e3a
Gerrit-Change-Number: 33964
Gerrit-PatchSet: 5
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-MessageType: merged
Attention is currently required from: jolly, pespin, fixeria.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33979 )
Change subject: ASCI: Add tests for voice group/broadcast calls at MSC
......................................................................
Patch Set 2: Code-Review+1
(1 comment)
File msc/BSC_ConnectionHandler.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33979/comment/ac0074f9_dc62…
PS2, Line 68: inout charstring, CallParameters, ASCI_Event;
> imho this makes general handlig of Coord port more difficult, since one needs to check for different […]
I would go the other way around: Why are there strings at all, and not more specific types going through the port? And regarding handling other messages: A simple default altstep that ignores all unsupported messages could be used to make old code backwards-compatible.
TTCN-3 is a strongly typed language. Sending strings between two parts of our own code looks like it was python or some kind of weakly typed language. There are all the usual problems associated with strings like making a typo on one end would only be discovered at runtime instead of compile time, ...
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33979
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I4bbe739ea55ecf9f7ebf9ee413df69f29aa642f8
Gerrit-Change-Number: 33979
Gerrit-PatchSet: 2
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
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: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 29 Jul 2023 08:52:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33976 )
Change subject: ASCI: Allow incoming VGCS/VBS connections at RAN_Emulation.ttcnpp
......................................................................
ASCI: Allow incoming VGCS/VBS connections at RAN_Emulation.ttcnpp
Similar to Handover Requests the RAN Emulation can accept new SCCP
connections with VGCS/VBS Setup message and VGCS/VBS Assignment Request
message. The point code for the incoming connection can be registered
in the same way as for the Handover Request.
In order to allow multiple connections with the same point code, the
table entry in the ExpectTable must be released after receiving the
message. VGCS/VBS calls have multiple connections to the same BSC.
This patch does not break existing MSC handover tests.
Related: OS#4854
Change-Id: I3fc0c5efe7d9f270804e7295aeb65cfe7898bd7e
---
M library/RAN_Emulation.ttcnpp
1 file changed, 31 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/library/RAN_Emulation.ttcnpp b/library/RAN_Emulation.ttcnpp
index 2fba50a..99753da 100644
--- a/library/RAN_Emulation.ttcnpp
+++ b/library/RAN_Emulation.ttcnpp
@@ -1348,6 +1348,14 @@
handoverRequest := true;
handoverRequestPointCode := bit2int(conn_ind.calledAddress.signPointCode);
log("ExpectedCreateCallback handoverRequest ", handoverRequestPointCode);
+ } else if (ischosen(conn_ind.userData.pdu.bssmap.vGCS_VBSSetup)) {
+ handoverRequest := true;
+ handoverRequestPointCode := bit2int(conn_ind.calledAddress.signPointCode);
+ log("ExpectedCreateCallback VGCS/VBS Setup ", handoverRequestPointCode);
+ } else if (ischosen(conn_ind.userData.pdu.bssmap.vGCS_VBSAssignmentRequest)) {
+ handoverRequest := true;
+ handoverRequestPointCode := bit2int(conn_ind.calledAddress.signPointCode);
+ log("ExpectedCreateCallback VGCS/VBS Assignment ", handoverRequestPointCode);
} else {
setverdict(fail, "N-CONNECT.ind with L3 != COMPLETE L3 nor a Handover Request");
mtc.stop;
@@ -1359,6 +1367,9 @@
" ==? ", handoverRequestPointCode);
if (ExpectTable[i].handoverRequestPointCode == handoverRequestPointCode) {
ret := ExpectTable[i].vc_conn;
+ /* release this entry to be used again */
+ ExpectTable[i].handoverRequestPointCode := omit;
+ ExpectTable[i].vc_conn := null;
log("Found Expect[", i, "] for handoverRequest handled at ", ret);
return ret;
} else {
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33976
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I3fc0c5efe7d9f270804e7295aeb65cfe7898bd7e
Gerrit-Change-Number: 33976
Gerrit-PatchSet: 2
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
Attention is currently required from: pespin.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/34005 )
Change subject: rlcmac: Initial selection of packet-access-procedure mode based on originating cause
......................................................................
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/34005
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-gprs
Gerrit-Branch: master
Gerrit-Change-Id: I930a1fcf23506f75562a6795f9a6e42b187d2974
Gerrit-Change-Number: 34005
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 29 Jul 2023 08:41:13 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: osmith, pespin.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/33970 )
Change subject: sm: Introduce APIs to enc/dec QoS Profile
......................................................................
Patch Set 2: Code-Review+2
(1 comment)
Patchset:
PS1:
> Regarding endianness, should we disable the check? it will keep on failing in all future patches if […]
I think it's safe to disable the check and then subsequently at low priority submit patches to the various projects to remove the related generated code.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/33970
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-gprs
Gerrit-Branch: master
Gerrit-Change-Id: I6c0676e55bb1f0f424f41d8d04d4f5e5bf376f4f
Gerrit-Change-Number: 33970
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
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-Comment-Date: Sat, 29 Jul 2023 08:40:15 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: osmith <osmith(a)sysmocom.de>
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/34006 )
Change subject: cosmetic: Document foce_two_phase feature based on specs
......................................................................
cosmetic: Document foce_two_phase feature based on specs
Change-Id: I4f8e3d0dcb721d51838b50aba5b40d0551c8d0c5
---
M src/bts.cpp
1 file changed, 15 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/src/bts.cpp b/src/bts.cpp
index 177544a..fe48018 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -970,6 +970,12 @@
LOGP(DRLCMAC, LOGL_DEBUG, "MS requests single TS uplink transmission "
"(one phase packet access)\n");
if (bts->pcu->vty.force_two_phase) {
+ /* 3GPP TS 44.018 3.5.2.1.3.1: "If the establishment cause in the
+ * CHANNEL REQUEST message indicates a request for one phase packet access,
+ * the network may grant either a one phase packet access or a single block
+ * packet access for the mobile station. If a single block packet access is
+ * granted, it forces the mobile station to perform a two phase packet access."
+ */
LOGP(DRLCMAC, LOGL_DEBUG, "Forcing two phase access\n");
chan_req.single_block = true;
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/34006
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I4f8e3d0dcb721d51838b50aba5b40d0551c8d0c5
Gerrit-Change-Number: 34006
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
Attention is currently required from: wbokslag.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/34001 )
Change subject: Added stub for decryption and full keystream application functions
......................................................................
Patch Set 2:
(2 comments)
File src/crypto/tetra_crypto.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34001/comment/87f12f9f_714dba42
PS2, Line 207: case KSG_TEA1:
: tea1_stub(iv, eck, num_bytes, ks_bytes);
: break;
: case KSG_TEA2:
: tea2_stub(iv, eck, num_bytes, ks_bytes);
: break;
: case KSG_TEA3:
: tea3_stub(iv, eck, num_bytes, ks_bytes);
: break;
I think it's a bit weird to add the stub functions that don't do anything in a commit here. This leads to situations that if somebody calls the function now, it returns success (true) despite not having generated the keystream. I think it would be wise to not merge the stub functions at all, and have generate_keystream run into the default-clause below which gives a proper error message and return code instead of silent failure.
https://gerrit.osmocom.org/c/osmo-tetra/+/34001/comment/cea1cccd_ff18f74c
PS2, Line 305: /
we typically prefer /* */ comments. Feels especially inconsistenc since this very same patch is adding multiple comments in different styles.
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/34001
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: I4e6147f206ad6046f32e08015ec9721b64382ca1
Gerrit-Change-Number: 34001
Gerrit-PatchSet: 2
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Comment-Date: Sat, 29 Jul 2023 08:37:51 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: wbokslag.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/34000 )
Change subject: Fixups and clarifying comments for msgb tail modifications
......................................................................
Patch Set 2:
(6 comments)
File src/lower_mac/tetra_lower_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/c28a8e8e_e37afbcb
PS2, Line 347: msg->len = msg
in general we don't ever manually manipulate msgb's this way in other osmocom software. We use the various msgb.[ch] functions as high-level operations on the buffer (like msgb_put/pull/push/get/trim/reserve/...), but don't consider manipulation of the individual fields as good code.
I don't know the specific use case here (and have too many other tasks to review in detail) so I don't have a concrete suggestion, just sharing general thoughts.
File src/tetra_llc.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/e33e4841_ee2edb49
PS2, Line 124: msg->tail = msg->l3h + lpp.tl_sdu_len; // Strips off FCS (if present)
: msg->len = msg->tail - msg->head;
this looks a bit like openn-coding a msgb_get(), or probably even more a msgb_l3trim() ?
File src/tetra_upper_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/68250cd6_9fecc52e
PS2, Line 178: msg->len = m
same here. msgb_trim?
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/7b1ffe59_7871231b
PS2, Line 185: msg->len = m
same here. msgb_trim?
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/edec0a07_0a8865b4
PS2, Line 306: msg->len = m
yet another msgb_trim? Also, the entire get_num_fill_bits + following operations happens several times in the code, so it might make sense to create a function to cover the sequence of getting the number of fill-bits and then trimming the message to exclude those?
https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/46364861_fc916427
PS2, Line 359: msg->len = m
again another fill-bits-stripping situation.
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/34000
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: Ia725edbeafe26bd2ea9b5a1810d0b26bc79d84db
Gerrit-Change-Number: 34000
Gerrit-PatchSet: 2
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Comment-Date: Sat, 29 Jul 2023 08:34:44 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: wbokslag.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/33997 )
Change subject: Added keyfile parsing code and various crypto improvements
......................................................................
Patch Set 2:
(1 comment)
File src/tetra-rx.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/33997/comment/4feb8f43_2f5936f7
PS2, Line 96: talloc
again, just FYI: talloc is hieararchical. If one would pass the tetra_mac_state as context pointer when allocationg the tcs (instead of NULL as you're doing), then talloc_free(tms) would automatically free the tcs.
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/33997
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: I1c7afeeb2dcf97ece44bb4b604f44ba88882b93f
Gerrit-Change-Number: 33997
Gerrit-PatchSet: 2
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Comment-Date: Sat, 29 Jul 2023 08:25:32 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment