January 2023 - gerrit-log - lists.osmocom.org

Change in osmo-ttcn3-hacks[master]: DIAMETER_Templates: Fix 3GPP Spec number

by laforge

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/31097 ) Change subject: DIAMETER_Templates: Fix 3GPP Spec number ...................................................................... DIAMETER_Templates: Fix 3GPP Spec number It's 3GPP TS 29.272, not 29.262. Change-Id: I33d437593a13a92151e33e86534e2189b541b5ea --- M library/DIAMETER_Templates.ttcn 1 file changed, 22 insertions(+), 22 deletions(-) Approvals: pespin: Looks good to me, but someone else must approve osmith: Looks good to me, approved Jenkins Builder: Verified diff --git a/library/DIAMETER_Templates.ttcn b/library/DIAMETER_Templates.ttcn index 964708f..67cd78d 100644 --- a/library/DIAMETER_Templates.ttcn +++ b/library/DIAMETER_Templates.ttcn @@ -563,7 +563,7 @@ -/* TS 29.262 7.3.53 RAND */ +/* TS 29.272 7.3.53 RAND */ template (value) GenericAVP ts_AVP_RAND(template (value) octetstring rand) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_RAND), @@ -573,7 +573,7 @@ } } -/* TS 29.262 7.3.54 XRES */ +/* TS 29.272 7.3.54 XRES */ template (value) GenericAVP ts_AVP_XRES(template (value) octetstring xres) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_XRES), @@ -583,7 +583,7 @@ } } -/* TS 29.262 7.3.55 XRES */ +/* TS 29.272 7.3.55 XRES */ template (value) GenericAVP ts_AVP_AUTN(template (value) octetstring autn) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_AUTN), @@ -593,7 +593,7 @@ } } -/* TS 29.262 7.3.56 KASME */ +/* TS 29.272 7.3.56 KASME */ template (value) GenericAVP ts_AVP_KASME(template (value) octetstring kasme) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_KASME), @@ -603,7 +603,7 @@ } } -/* TS 29.262 7.3.23 Item-Number */ +/* TS 29.272 7.3.23 Item-Number */ template (value) GenericAVP ts_AVP_ItemNumber(uint32_t num) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_KASME), @@ -613,7 +613,7 @@ } } -/* TS 29.262 7.3.18 E-UTRAN Vector */ +/* TS 29.272 7.3.18 E-UTRAN Vector */ template (value) GenericAVP ts_AVP_EutranVec(uint32_t item_num, octetstring rand, octetstring xres, octetstring autn, octetstring kasme) := { avp := { @@ -630,7 +630,7 @@ } } -/* TS 29.262 7.3.2 Subscription-Data */ +/* TS 29.272 7.3.2 Subscription-Data */ template (value) GenericAVP ts_AVP_3GPP_SubscriptionData(template (value) AVP_list content) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_Subscription_Data), @@ -650,7 +650,7 @@ } -/* TS 29.262 7.3.17 Authentication-Info */ +/* TS 29.272 7.3.17 Authentication-Info */ template (value) GenericAVP ts_AVP_3GPP_AuthInfo(template (value) AVP_list content) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_Authentication_Info), @@ -669,7 +669,7 @@ } } -/* TS 29.262 7.3.9 Visited-PLMN-Id */ +/* TS 29.272 7.3.9 Visited-PLMN-Id */ template (value) GenericAVP ts_AVP_3GPP_VisitedPlmnId(template (value) octetstring id) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_Visited_PLMN_Id), @@ -687,7 +687,7 @@ } } -/* TS 29.262 7.3.13 RAT-Type */ +/* TS 29.272 7.3.13 RAT-Type */ template (value) GenericAVP ts_AVP_PCC_3GPP_RatType(template (value) PCC_3GPP_RAT_Type rat_type) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_PCC_3GPP_RAT_Type), @@ -714,7 +714,7 @@ } } -/* TS 29.262 7.3.7 ULR-Flags */ +/* TS 29.272 7.3.7 ULR-Flags */ template (value) GenericAVP ts_AVP_3GPP_UlrFlags(template (value) UINT32 flags) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_ULR_Flags), @@ -732,7 +732,7 @@ } } -/* TS 29.262 7.3.8 ULA-Flags */ +/* TS 29.272 7.3.8 ULA-Flags */ template (value) GenericAVP ts_AVP_3GPP_UlaFlags(template (value) UINT32 flags) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_ULA_Flags), @@ -785,7 +785,7 @@ } -/* TS 29.262 7.3.27 Context-Identifier */ +/* TS 29.272 7.3.27 Context-Identifier */ template (value) GenericAVP ts_AVP_3GPP_ContextId(uint32_t ctx) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_Context_Identifier), @@ -795,7 +795,7 @@ } } -/* Ts 29.262 7.3.29 Subscriber-Status */ +/* Ts 29.272 7.3.29 Subscriber-Status */ template (value) GenericAVP ts_AVP_3GPP_SubscriberStatus(template (value) AAA_3GPP_Subscriber_Status sts) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_Subscriber_Status), @@ -814,7 +814,7 @@ } } -/* TS 29.262 7.3.33 All-APN-Configurations-Included-Indicator */ +/* TS 29.272 7.3.33 All-APN-Configurations-Included-Indicator */ template (value) GenericAVP ts_AVP_3GPP_AllApnConfigsIncl(template (value) AAA_3GPP_All_APN_Configurations_Included_Indicator ind := All_APN_CONFIGURATIONS_INCLUDED) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_All_APN_Configurations_Included_Indicator), @@ -824,7 +824,7 @@ } } -/* TS 29.262 7.3.34 APN-Configuration-Profile */ +/* TS 29.272 7.3.34 APN-Configuration-Profile */ template (value) GenericAVP ts_AVP_3GPP_ApnConfigProfile(template (value) AVP_list content) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_APN_Configuration_Profile), @@ -834,7 +834,7 @@ } } -/* TS 29.262 7.3.35 APN-Configuration */ +/* TS 29.272 7.3.35 APN-Configuration */ template (value) GenericAVP ts_AVP_3GPP_ApnConfig(uint32_t ctx, AAA_3GPP_PDN_Type pdn_type, charstring apn) := { avp := { @@ -850,7 +850,7 @@ } } -/* TS 29.262 7.3.36 Service-Selection (refers to RFC 5778) */ +/* TS 29.272 7.3.36 Service-Selection (refers to RFC 5778) */ template (value) GenericAVP ts_AVP_ServiceSelection(charstring apn) := { avp := { avp_header := ts_DIA_Hdr(c_AVP_Code_MIPv6_NONE_Service_Selection), @@ -949,7 +949,7 @@ } -/* TS 29.262 7.3.41 AMBR */ +/* TS 29.272 7.3.41 AMBR */ template (value) GenericAVP ts_AVP_3GPP_AMBR(uint32_t ul, uint32_t dl) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_AMBR), @@ -1142,7 +1142,7 @@ } } -/* TS 29.262 7.3.62 PDN-Type */ +/* TS 29.272 7.3.62 PDN-Type */ template (value) GenericAVP ts_AVP_3GPP_PdnType(template (value) AAA_3GPP_PDN_Type pdn_type) := { avp := { avp_header := ts_DIA_Hdr_3GPP(c_AVP_Code_AAA_3GPP_PDN_Type), @@ -1348,7 +1348,7 @@ tr_AVP_3GPP_VisitedPlmnId )); -/* TS 29.262 5.2.3.1 + 7.2.6 Authentication Information Answer */ +/* TS 29.272 5.2.3.1 + 7.2.6 Authentication Information Answer */ template (value) PDU_DIAMETER ts_DIA_AIA(template (value) AVP_list auth_info_contents, template (value) octetstring sess_id := c_def_sess_id, @@ -1391,7 +1391,7 @@ )); -/* TS 29.262 7.2.3 Update Location Request */ +/* TS 29.272 7.2.3 Update Location Request */ template (value) PDU_DIAMETER ts_DIA_ULR(/* template (value) */ hexstring imsi, template (value) octetstring sess_id := c_def_sess_id, -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/31097 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: I33d437593a13a92151e33e86534e2189b541b5ea Gerrit-Change-Number: 31097 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

2 years, 6 months

1
0
0 0

Change in osmo-msc[master]: After RX of an SMPP Submit, send the SMS we just received.

by keith

Attention is currently required from: neels, laforge. keith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/28342 ) Change subject: After RX of an SMPP Submit, send the SMS we just received. ...................................................................... Patch Set 2: (1 comment) Patchset: PS2: > Out of many things I could understand I may have miscommunicated, I can't see how I have suggested t […] Uh.. reading this entire thread.. I've ended up write essays on gerrit recently 😞 I realise there's an incongruency. To be clear: I do think it is better to try to deliver the SMS on receipt, that is to say: add it to the in memory "sms-queue", rather than just drop it into the database and wait/hope for the database getter to load it into the in-memory sms-queue. The reason why I mentioned above that something "makes these patches unnecessary" is two-fold: 1) complete removal of sms-queue from osmo-msc. - much talked about at times, but I'm not holding my breath for it. 2) removal of the sqlite based storage which allows a more aggressive storage to in-memory queue getter, which somewhat mitigates the problem. -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28342 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9af51ef0d9c2e6c5acc5128efd6195df881b680c Gerrit-Change-Number: 28342 Gerrit-PatchSet: 2 Gerrit-Owner: keith <keith(a)rhizomatica.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Mon, 30 Jan 2023 18:38:21 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: keith <keith(a)rhizomatica.org> Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-msc[master]: After RX of an SMPP Submit, send the SMS we just received.

by keith

Attention is currently required from: neels, laforge. keith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/28342 ) Change subject: After RX of an SMPP Submit, send the SMS we just received. ...................................................................... Patch Set 2: (2 comments) Patchset: PS2: > if this patch helps you in production setups, and it has been tested/verified there, please rebase a […] Out of many things I could understand I may have miscommunicated, I can't see how I have suggested that it "hardly matters". I think that delivering a sent SMS as soon as possible is rather important. I think I explained why this isn't happening. It's also been observed at the congress event. PS2: > if this patch helps you in production setups, and it has been tested/verified there, please rebase a […] This patch is actually part of a larger patch set that I am currently running in production setup. Some of the other patches had been submitted here, including https://gerrit.osmocom.org/c/osmo-msc/+/28338/1 which was abandoned due to your valid comment there: "... It creates a merge nightmare for all of my work on a SQL-less SMS storage backend... " The patch set that I am running, is not experiencing the bizarre, up to some minutes of duration stalls that we observed last year related to sqlite driver? or disk access/locking? or who knows what? - I remember well that after valiant attempts to figure out what was going on, the conclusion was something like: I don't care (anymore) what sqlite is doing, let's simply remove it, hence your sprint to implement file based storage for the SMS queue.. I do not know which patch(es) is/are avoiding the lockups, but I have a feeling it has to do with all or some of: 1) not rapidly doing UPDATE followed by DELETE operations. 2) implementing a timer to prevent successive queue runs (possibly giving the sqlite/disk IO or I don't know what a chance to "catch up"? My hypothesis is that current master osmo-msc continues to suffer from this stalling problem and I think it will be observed if there is significant SMS traffic, at for example a CCC event. Therefore, I don't see much point in submitting this patch alone. - This patch simply addresses an issue that I noticed while doing a pretty intense analysis of the SMS queue. This issue would be relevant regardless of the actual storage backend, if the queue is large enough. A possibility for me at this point is: rebase and resumbit all the patches relevant to sqlite based SMS-Q and rebase laforge/nosql on top of that work. I don't know how complicated that might be, but it could be a solution to not creating that work for somebody else by merging the sqlite work to master. At the same time, I'm not necessarily happy with the sqlite work as I don't know EXACTLY why it alleviates the problem and I have -ENOTEXIST desire to push patches that I do not understand through CR, or to create more pending patches that sit like this one for six months. Maybe worth also saying that dropping sqlite and switching to file based SMS storage also creates a work load for me in that I have to adapt code that I run to deal with that. Mostly, the routine that checks for SMS sitting in local queue for a destination that is currently attached to another VLR, (distributed-GSM-SMSQ if you like) But it's probably as simple as changing the db access routines to file access routines. -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28342 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9af51ef0d9c2e6c5acc5128efd6195df881b680c Gerrit-Change-Number: 28342 Gerrit-PatchSet: 2 Gerrit-Owner: keith <keith(a)rhizomatica.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Mon, 30 Jan 2023 18:29:29 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: keith <keith(a)rhizomatica.org> Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-bsc[master]: pcu_sock: complain when not PDCH is available at all

by fixeria

Attention is currently required from: pespin, dexter. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/31111 ) Change subject: pcu_sock: complain when not PDCH is available at all ...................................................................... Patch Set 1: (2 comments) Patchset: PS1: > I don't really see the point in printing that information, specially as NOTICE. […] Agreeing with Pau here. File src/osmo-bsc/pcu_sock.c: https://gerrit.osmocom.org/c/osmo-bsc/+/31111/comment/b6505260_24c55144 PS1, Line 165: found_pdch no need for an additional variable, simply check if: trx_info->pdch_mask == 0. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/31111 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: Ie3e5409cd798f6027404c0ff95297af850e516c4 Gerrit-Change-Number: 31111 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 18:28:51 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-bsc[master]: pcu_sock: clean up logging in info_ind_fill_trx

by fixeria

Attention is currently required from: dexter. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/30850 ) Change subject: pcu_sock: clean up logging in info_ind_fill_trx ...................................................................... Patch Set 9: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/30850 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: Ie5c1abcf7b25fe00b6c228c49648e018f94190f0 Gerrit-Change-Number: 30850 Gerrit-PatchSet: 9 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-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 18:22:46 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-bsc[master]: pcu_sock: fix sourcecode formatting

by fixeria

Attention is currently required from: dexter. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/31110 ) Change subject: pcu_sock: fix sourcecode formatting ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/31110 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I593c16efa1639aa8d2f90735bfdc9750cf695ecd Gerrit-Change-Number: 31110 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 18:08:43 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmocom-bb[master]: trxcon: Fix heap-use-after-free in l1ctl_client

by pespin

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/31109 ) Change subject: trxcon: Fix heap-use-after-free in l1ctl_client ...................................................................... trxcon: Fix heap-use-after-free in l1ctl_client If the peer connected to trxcon restarts the process, read() on the unix socket in trxcon fails, and triggers closing the conn (l1ctl_client), which ends up freeing the struct. This all happens during read_cb() of the l1ctl_client wqueue. If the kernel also flags WRITE event in the same main loop iteration, the wqueue code would end up using the freed struct again when running the write_cb. Make sure the read_cb returns -EBADF in the code branch closing the conn in read_cb, since it makes no sense to handle a write_cb after that. This saves the code from accessing the potentially freed struct. Related: OS#5872 Change-Id: I100a8ba056a09b4e52675e3539640da0c0f8d837 --- M src/host/trxcon/src/l1ctl_server.c 1 file changed, 1 insertion(+), 1 deletion(-) Approvals: Jenkins Builder: Verified fixeria: Looks good to me, approved diff --git a/src/host/trxcon/src/l1ctl_server.c b/src/host/trxcon/src/l1ctl_server.c index bfbd997..c0f1015 100644 --- a/src/host/trxcon/src/l1ctl_server.c +++ b/src/host/trxcon/src/l1ctl_server.c @@ -61,7 +61,7 @@ rc = -EIO; } l1ctl_client_conn_close(client); - return rc; + return -EBADF; /* client fd is gone, avoid processing any other events. */ } /* Check message length */ -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/31109 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I100a8ba056a09b4e52675e3539640da0c0f8d837 Gerrit-Change-Number: 31109 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

2 years, 6 months

1
0
0 0

Change in osmocom-bb[master]: trxcon: Fix heap-use-after-free in l1ctl_client

by fixeria

Attention is currently required from: pespin. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/31109 ) Change subject: trxcon: Fix heap-use-after-free in l1ctl_client ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/31109 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I100a8ba056a09b4e52675e3539640da0c0f8d837 Gerrit-Change-Number: 31109 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 17:48:54 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-bsc[master]: pcuif_proto: add indication to communicate E1 parameters

by pespin

Attention is currently required from: dexter. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/31113 ) Change subject: pcuif_proto: add indication to communicate E1 parameters ...................................................................... Patch Set 1: (4 comments) Commit Message: https://gerrit.osmocom.org/c/osmo-bsc/+/31113/comment/9b295746_0d1474b0 PS1, Line 10: setup. To avioud duplicate configuration the BSC has to communicate the "avoid" https://gerrit.osmocom.org/c/osmo-bsc/+/31113/comment/968f1de1_6913b767 PS1, Line 11: E1 parameters (which TS, SS etc.) to the PCU. Lets add a new primitive What do you mean with "to avoid duplicate configuration" here? where would the duplicate configuration be? what would the other way be? File include/osmocom/bsc/pcuif_proto.h: https://gerrit.osmocom.org/c/osmo-bsc/+/31113/comment/914f87e2_5196a3c6 PS1, Line 263: uint8_t pdch_trx_no; this was not yet changed to trx_nr, why? https://gerrit.osmocom.org/c/osmo-bsc/+/31113/comment/7de699c2_f0b4dd12 PS1, Line 264: uint8_t pdch_ts; this was not yet changed to ts_nr, why? -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/31113 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: Ia7928489130c1205b06bb9b10de0fb1461843301 Gerrit-Change-Number: 31113 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 17:42:19 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

Change in osmo-bsc[master]: pcu_sock: fix sourcecode formatting

by pespin

Attention is currently required from: dexter. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/31110 ) Change subject: pcu_sock: fix sourcecode formatting ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/31110 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I593c16efa1639aa8d2f90735bfdc9750cf695ecd Gerrit-Change-Number: 31110 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 30 Jan 2023 17:39:05 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 6 months

1
0
0 0

2025

2024

2023

2022

gerrit-log January 2023