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

[M] Change in osmo-hnbgw[master]: immediately SCCP RLSD on HNB re-register

by neels

Attention is currently required from: laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 ) Change subject: immediately SCCP RLSD on HNB re-register ...................................................................... Patch Set 3: Code-Review+1 (1 comment) Patchset: PS3: re-add previous vote after trivial commit log tweak -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1 Gerrit-Change-Number: 32915 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 21:22:10 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[M] Change in osmo-hnbgw[master]: immediately SCCP RLSD on HNB re-register

by neels

Attention is currently required from: laforge, pespin. Hello Jenkins Builder, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 to look at the new patch set (#3). Change subject: immediately SCCP RLSD on HNB re-register ...................................................................... immediately SCCP RLSD on HNB re-register The RUA side may disconnect a) gracefully (RUA Disconnect with RANAP IU Release Complete) or b) by detecting that the HNB is gone / has restarted For a), the SCCP side waits for a RLSD from the CN that follows the IU Release Complete. For b), we so far also wait for a RLSD from CN, which will never come, and only after a timeout send an SCCP RLSD to the CN. Instead, for b), immediately send an SCCP RLSD. To distinguish between the graceful release (a) and the disruptive release (b), add new state MAP_RUA_ST_DISRUPTED on the RUA side, and add new event MAP_SCCP_EV_RAN_LINK_LOST for the SCCP side. Any non-graceful disconnect of RUA enters ST_DISRUPTED. disrupted_onenter() dispatches EV_RAN_LINK_LOST to SCCP, and SCCP directly sends RLSD to the CN without timeout. These changes are also shown in doc/charts/hnbgw_context_map.msc. Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1 --- M doc/charts/hnbgw_context_map.msc M include/osmocom/hnbgw/context_map.h M src/osmo-hnbgw/context_map_rua.c M src/osmo-hnbgw/context_map_sccp.c 4 files changed, 95 insertions(+), 15 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/15/32915/3 -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1 Gerrit-Change-Number: 32915 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newpatchset

2 years, 1 month

1
0
0 0

[M] Change in osmo-hnbgw[master]: immediately SCCP RLSD on HNB re-register

by neels

Attention is currently required from: laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 ) Change subject: immediately SCCP RLSD on HNB re-register ...................................................................... Patch Set 2: (2 comments) Patchset: PS1: > Ok, but I think you didn't mention the RUA_Disconnect message there, now it's clearer. /me adds "RUA" to commit msg File src/osmo-hnbgw/context_map_sccp.c: https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915/comment/3e0d8a16_714e474c PS1, Line 362: tx_sccp_df1(fi, ranap_msg); : tx_sccp_rlsd(fi); > I think "dispatch" or "submit" are better candidates than "transmit" or "send" when passing stuff ac […] ok. i'm still a bit unclear, is this about only tx_sccp_rlsd() or also the other one? in my POV both functions already have the best names -- they both transmit actual SCCP packets on the wire, by asking the SCCP user sap. So may I ask reviewers to just tell me which function(s) to rename to exactly what and I can do that. In every case that would happen in a separate patch. If there's no opposition, I'm going to click on 'Resolved' here, from the perspective of review on the changes of *this* patch. -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1 Gerrit-Change-Number: 32915 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 21:20:25 +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: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[S] Change in libosmocore[master]: gsm: fix convolutional code definition for TCH/F4.8

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/32986 ) Change subject: gsm: fix convolutional code definition for TCH/F4.8 ...................................................................... gsm: fix convolutional code definition for TCH/F4.8 The block length for TCH/F4.8 is off by 4 bits. Value 152 matches with what TS 45.003 section 3.4.3 defines, but for some reason the encoder generates more bits (468) than it must (456). This results in buffer overruns when encoding TCH/F4.8. All block length values in conv_codes_gsm.py are 4 bits less than the respective values in TS 45.003. I have no idea why... Change-Id: Id86d1aa0fd6791a8be431b5547bb723c74c35757 Related: OS#1572 --- M tests/conv/conv_gsm0503_test.ok M utils/conv_codes_gsm.py 2 files changed, 21 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/86/32986/1 diff --git a/tests/conv/conv_gsm0503_test.ok b/tests/conv/conv_gsm0503_test.ok index bfefcd0..6fd3793 100644 --- a/tests/conv/conv_gsm0503_test.ok +++ b/tests/conv/conv_gsm0503_test.ok @@ -15,8 +15,8 @@ [..] Encoding / Decoding cycle : OK [+] Testing: gsm0503_tch_f48 -[.] Input length : ret = 152 exp = 152 -> OK -[.] Output length : ret = 468 exp = 468 -> OK +[.] Input length : ret = 148 exp = 148 -> OK +[.] Output length : ret = 456 exp = 456 -> OK [.] Random vector checks: [..] Encoding / Decoding cycle : OK [..] Encoding / Decoding cycle : OK diff --git a/utils/conv_codes_gsm.py b/utils/conv_codes_gsm.py index a6e471e..721e546 100644 --- a/utils/conv_codes_gsm.py +++ b/utils/conv_codes_gsm.py @@ -68,7 +68,7 @@ # TCH/F4.8 definition ConvolutionalCode( - 152, + 148, [ (G1, 1), (G2, 1), -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/32986 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Id86d1aa0fd6791a8be431b5547bb723c74c35757 Gerrit-Change-Number: 32986 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newchange

2 years, 1 month

1
0
0 0

[M] Change in libosmo-gprs[master]: rlcmac: Add APIs to decode P1/P2 Rest Octets

by fixeria

Attention is currently required from: pespin. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/32972 ) Change subject: rlcmac: Add APIs to decode P1/P2 Rest Octets ...................................................................... Patch Set 1: Code-Review+1 (2 comments) File include/osmocom/gprs/rlcmac/csn1_defs.h: https://gerrit.osmocom.org/c/libosmo-gprs/+/32972/comment/6d037101_61767543 PS1, Line 5369: const uint8_t *data, size_t data_len); alignment here and below File src/rlcmac/csn1_ts_44_018.c: https://gerrit.osmocom.org/c/libosmo-gprs/+/32972/comment/59822109_d49f1f19 PS1, Line 672: } " No newline at end of right file. " -- To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/32972 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-gprs Gerrit-Branch: master Gerrit-Change-Id: I59c6723d969880a4481e3b86a172d59f0edeb1e4 Gerrit-Change-Number: 32972 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: Wed, 24 May 2023 18:02:31 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[S] Change in osmo-bts[master]: trx, HR1 codec: change UL PHY output format to TS 101 318

by dexter

Attention is currently required from: falconia, fixeria. dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32969 ) Change subject: trx, HR1 codec: change UL PHY output format to TS 101 318 ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > Right now I am setting the default to RFC 5993 for all BTS models - but I now see that your comment […] Yes, I think its best to tie the default value to the BTS model. You can use BTS feature flags for that, like in this change: I9419b40c1171876879d41aba4f51c93e8ef5673c -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32969 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I41bce6226964975cb85aea89e4c0f9e11e4929b8 Gerrit-Change-Number: 32969 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 17:54:11 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[M] Change in osmo-bts[master]: all models, HR1 codec: select RTP output format via vty option

by dexter

Attention is currently required from: laforge, pespin, dexter. dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32970 ) Change subject: all models, HR1 codec: select RTP output format via vty option ...................................................................... Patch Set 1: (1 comment) File src/common/bts.c: https://gerrit.osmocom.org/c/osmo-bts/+/32970/comment/99b9cf1d_525c3628 PS1, Line 333: bts->emit_hr_rfc5993 = true; I am not sure if it is wise to have a static default. I am a bit worried about existing deployments. A user of a DSP based BTS might rely on it using TS 101318 format. So after an update the deployment may cease to work. This is something to keep in mind. I would use the BTS feature flags, like in this change: I9419b40c1171876879d41aba4f51c93e8ef5673c -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32970 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I168191874a062429a57904511a1e89e3f588732e Gerrit-Change-Number: 32970 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: dexter <pmaier(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 17:50:18 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[M] Change in osmo-bts[master]: all models, HR1 codec: select RTP output format via vty option

by falconia

Attention is currently required from: laforge, pespin, dexter. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32970 ) Change subject: all models, HR1 codec: select RTP output format via vty option ...................................................................... Patch Set 1: (3 comments) File include/osmo-bts/bts.h: https://gerrit.osmocom.org/c/osmo-bts/+/32970/comment/77bbed4e_7ea9a729 PS1, Line 303: bool emit_hr_rfc5993; > maybe an enum specific type would be better here, but not sure if such an enum exists already. There is no existing enum. If such enum did already exist, I would certainly use it, but do we really need to go to the trouble of creating one just for this purpose? File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/32970/comment/e190af5d_fe5b066e PS1, Line 1705: send_rtp_rfc5993(lchan, fn, msg->data, msg->len); > agreed. Let's be smart in msgb usage rathe than andding memcpy/memmove/... Good point. I shall investigate to make sure that the necessary headroom does exist, and then make the change. File src/common/vty.c: https://gerrit.osmocom.org/c/osmo-bts/+/32970/comment/fd0cbe4d_3fc3971c PS1, Line 802: DEFUN(cfg_bts_rtp_hr_format, > As far as I can see the bts->emit_hr_rfc5993 is checked on every l1sap_tch_ind. […] Point taken - I shall look into doing what you suggest. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32970 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I168191874a062429a57904511a1e89e3f588732e Gerrit-Change-Number: 32970 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: dexter <pmaier(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 17:48:02 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[S] Change in osmo-bts[master]: all models, HR1 codec: accept both TS101318 and RFC5993 formats

by falconia

Attention is currently required from: laforge, pespin, dexter. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32968 ) Change subject: all models, HR1 codec: accept both TS101318 and RFC5993 formats ...................................................................... Patch Set 1: (3 comments) File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/a3452940_ea23b703 PS1, Line 1264: static bool rtppayload_validate_hr(struct msgb *msg) > this function is now not really validating, but converting. The same is already the case for rtppayload_validate_{fr,efr} - those functions call osmo_{fr,efr}_sid_preen(), and the latter functions apply a transformation to the bits: if the received frame was a deemed-valid SID with some bit errors, that SID is rejuvenated by clearing all those errored bits. Should we perhaps rename all these functions to rtppayload_preen_*() instead of validate? Please ack if I should make a preliminary patch renaming the two existing functions and then use the new name in the next spin of the present patch. https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/dece4921_02b17e31 PS1, Line 1270: case GSM_HR_BYTES_RTP_RFC5993: > I'm not against this patch, I don't even know whether any of the existing backends is already using […] I concur with @laforge, and my initial thoughts on how to approach OS#5688 on the fundamental design level (before going down to code implementation level) were/are based on the same principle: it is unreasonable to anticipate new hypothetical DSP backends that would differ from what we have currently. @pespin: > I don't even know whether any of the existing backends is already using it. Prior to recent libosmocoding fixes, there was this issue: the channel encoding function used by osmo-bts-trx stupidly required 15-byte format even though it never actually looked at the ToC octet. That design bug is now fixed in libosmocoding in a backward-compatible way (that's what the Depends: line in the present patch refers to), and now that same function happily accepts 14-byte payloads. https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/d0e73f23_4d1f3678 PS1, Line 1279: memmove(msg->data, msg->data + 1, GSM_HR_BYTES); : msgb_get(msg, 1); > I'm wondering why we are moving data around in the msgb? This is potentially quite expensive on our […] Please read the long C comment on the 7 lines immediately preceding your highlight. The obvious msgb_pull() way was the first thing I tried, quite naturally, but it immediately brought the sysmoBTS unit to its knees! The visible symptoms were: as soon as that code path starts executing (as soon as RTP packets come in that require this one octet stripping), the MS on the test call would declare radio link failure, I seem to recall other MS also going into No Service because they stopped receiving PCH, and the vty telnet session was slowed to a crawl. I reason that the bad behavior is caused by misaligned accesses to 32-bit fields inside the l1sap header being added by l1sap_tch_rts_ind() - that header becomes misaligned once the msgb_pull() moves off the aligned position by 1 byte. I agree with you that the memmove way is inefficient - but the simple way doesn't work right now. Can we perhaps brainstorm some better way? -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32968 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e Gerrit-Change-Number: 32968 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 17:37:54 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

[M] Change in osmo-bts[master]: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload

by fixeria

Attention is currently required from: dexter. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32630 ) Change subject: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload ...................................................................... Patch Set 5: -Code-Review -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32630 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I9419b40c1171876879d41aba4f51c93e8ef5673c Gerrit-Change-Number: 32630 Gerrit-PatchSet: 5 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 17:36:58 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

2 years, 1 month

1
0
0 0

2025

2024

2023

2022

gerrit-log May 2023