Attention is currently required from: laforge.
dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/aram-applet/+/39615?usp=email )
Change subject: AccessRuleMaster: allow locking of STORE DATA commands
......................................................................
Patch Set 2:
(4 comments)
Patchset:
PS2:
Thanks for your review input.
File aram/src/main/java/fr/bmartel/aram/AccessRuleMaster.java:
https://gerrit.osmocom.org/c/aram-applet/+/39615/comment/bf633831_f7220c0e?… :
PS2, Line 106: ISOException.throwIt(ISO7816.SW_SECURITY_STATUS_NOT_SATISFIED);
> why is this exception not raised in the INSTALL FOR PERSO case? The only condition for raising it is […]
This is part of the scheme. As far as I understand INSTALL FOR PERSONALIZATION can only be issued from a secure channel with the ISD.
The process() method is executed when APDUs are sent to the application when it is selected. Here we have no authentication but we can set this.aram_lock_status to true, which will make processCmdStoreData() inaccessible for normal users.
In processData() we do not have this blocking logic because this method is only accessible from a secure channel from the ISD.
This is at least how I understood the world. Please correct me if I am wrong. If there is a way to call processData() without beeing authenticated, then my Idea will not work of course.
https://gerrit.osmocom.org/c/aram-applet/+/39615/comment/76ea6920_a805e0ee?… :
PS2, Line 304: this.aram_lock_status = true;
> mixing tab (new) and space (old) indentation
Done
https://gerrit.osmocom.org/c/aram-applet/+/39615/comment/6640b8f9_3cfe7173?… :
PS2, Line 307: this.aram_lock_status = false;
> where is the check that this command is only issued via the INSTALL FOR PERSO ?
This method is called from processData() and process(). As far as I know processData only runs when INSTALL FOR PERSONALIZATION is executed. So from that perspective we should be fine. When the method is called from process() this.aram_lock_status is checked first, so the executions barred when this.aram_lock_status is true (see line 105). I think this should be sufficient.
--
To view, visit https://gerrit.osmocom.org/c/aram-applet/+/39615?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: aram-applet
Gerrit-Branch: master
Gerrit-Change-Id: I86437844585c22fc4280cc48b99edbb56e3159db
Gerrit-Change-Number: 39615
Gerrit-PatchSet: 2
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Tue, 04 Mar 2025 08:56:54 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Attention is currently required from: csaba.sipos, laforge.
Hello Jenkins Builder, laforge,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-bsc/+/39652?usp=email
to look at the new patch set (#6).
The following approvals got outdated and were removed:
Code-Review+1 by laforge
Change subject: nokia_site: add function to unlock and reset TRXes
......................................................................
nokia_site: add function to unlock and reset TRXes
We have a long outstanding issue with TRX RSL bootstrap,
espcially with BTSes with more than one TRX. The more TRX
a BTS has, the more time it takes for it get to a ready state.
This commit changes the TRX bootstrap logic as the following:
1. During OML initial config, all TRXes are configured locked.
This gives a better controled state of TRXes, and the BTS
enough time to do internal checks, SW load etc.
2. BTS_CONF_COMPL usde as entry point for the RSL bootstrap.
3. Unlock all TRXes, and give the BCCH TRX a reset.
4. Start RSL bootstrap.
Runtime tested with InSite and a MetroSite with 4 TRXes.
Co-authored by: Tomcsányi Domonkos <domi(a)tomcsanyi.net>
Change-Id: I9042a1e24f0932a23a26185181481db2ceddbb7c
---
M src/osmo-bsc/bts_nokia_site.c
1 file changed, 73 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/52/39652/6
--
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/39652?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I9042a1e24f0932a23a26185181481db2ceddbb7c
Gerrit-Change-Number: 39652
Gerrit-PatchSet: 6
Gerrit-Owner: csaba.sipos <metro4(a)freemail.hu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: csaba.sipos <metro4(a)freemail.hu>
Attention is currently required from: osmith, pespin.
laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/39398?usp=email )
Change subject: ASP loadsharing: Pass xua_msg down to xua_as_transmit_msg
......................................................................
Patch Set 9: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/39398?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: I70e5d33c7537dc0b72b5abced876e69018cc0829
Gerrit-Change-Number: 39398
Gerrit-PatchSet: 9
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: Tue, 04 Mar 2025 06:19:03 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Attention is currently required from: falconia.
laforge has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39669?usp=email )
Change subject: trau_frame encode8_hr: simplify setting of C5 for odd parity
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
I'm not entirely sure if this optimization is worth it. It feels like it's premature in a sense that it will bite us in the butt if we ever want to change anything about this function, and the strange assumption no longer holds true.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39669?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmo-abis
Gerrit-Branch: master
Gerrit-Change-Id: I30c7dfdaaadd0fd4cb084cf02c66c0f19a40ae42
Gerrit-Change-Number: 39669
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: falconia <falcon(a)freecalypso.org>
Gerrit-Comment-Date: Tue, 04 Mar 2025 06:18:34 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Attention is currently required from: pespin.
laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/39661?usp=email )
Change subject: stp: Fix brokeness in STP_Tests_IPA.TC_tmt_loadshare
......................................................................
Patch Set 2: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/39661?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I61c3efbf8e30533d051e2de506f7c8eaae7e297b
Gerrit-Change-Number: 39661
Gerrit-PatchSet: 2
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: Tue, 04 Mar 2025 06:15:53 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39668?usp=email )
Change subject: trau_frame cosmetic: document exact behavior for C1..C5
......................................................................
trau_frame cosmetic: document exact behavior for C1..C5
For historical reasons, osmo_trau_frame_encode() API has quirky
behavior with regard to output of control bits C1..C5: for some
frame types these bits are set to user-controlled values taken
from fr->c_bits[], yet for other frame types the function fills
in what it "knows" to be the correct frame type code, ignoring
the first 5 bits out of user-supplied fr->c_bits[]. One particular
combination of frame type and direction is even more bizarre,
taking only fr->c_bits[3] while fixing the other 4 C-bits.
Unfortunately this behavior cannot be changed without breaking
API compatibility with previous released versions, i.e., without
breaking external applications that rely on this library behavior.
Therefore, we do the next best thing: thoroughly and succinctly
document these quirks.
Change-Id: Id1824c7cc8845ee2a730d556bec807c3cfa75beb
---
M src/trau/trau_frame.c
1 file changed, 19 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-abis refs/changes/68/39668/1
diff --git a/src/trau/trau_frame.c b/src/trau/trau_frame.c
index b8085c2..652c703 100644
--- a/src/trau/trau_frame.c
+++ b/src/trau/trau_frame.c
@@ -1246,6 +1246,25 @@
* where C1..C5 may need to be modified (especially TFO-AMR where this C1..C5
* modification must be done before CRC computation), please use
* osmo_trau_frame_encode_tfo().
+ *
+ * The following list summarizes the behavior of the present function with
+ * regard to C1..C5 bits for different frame types:
+ *
+ * - For all TRAU-16k frame types in both UL and DL directions, and for
+ * OSMO_TRAU8_SPEECH (TRAU-8k for HRv1 speech) in UL direction, the first 5
+ * bits of fr->c_bits[] are ignored and replaced with internally supplied
+ * constant values.
+ *
+ * - For OSMO_TRAU8_SPEECH in DL direction, only fr->c_bits[3] is used to set
+ * C4; constant values for C1..C3 and odd parity value for C5 are fixed
+ * by the function.
+ *
+ * - For OSMO_TRAU8_DATA, OSMO_TRAU8_OAM and all AMR-8k frame types,
+ * user-supplied fr->c_bits[] are always used.
+ *
+ * This unfortunate manipulation applies only to C1..C5 as listed above;
+ * for control bits C6 and higher (for frame types that have them),
+ * user-supplied fr->c_bits[] are always used.
*/
int osmo_trau_frame_encode(ubit_t *bits, size_t n_bits, const struct osmo_trau_frame *fr)
{
--
To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39668?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: libosmo-abis
Gerrit-Branch: master
Gerrit-Change-Id: Id1824c7cc8845ee2a730d556bec807c3cfa75beb
Gerrit-Change-Number: 39668
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>