Attention is currently required from: pespin.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/29424 )
Change subject: osmux: Log sendto() error
......................................................................
Patch Set 1: Code-Review+1
(1 comment)
File src/common/osmux.c:
https://gerrit.osmocom.org/c/osmo-bts/+/29424/comment/f979d8a3_c1897a0b
PS1, Line 96: strerror_r
Why not just using strerror()? osmo-bts is single-thread, and (I hope) will unlikely be multi-thread...
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/29424
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I195ebe0fdb05195a7f3b1390630e83084b5dea3a
Gerrit-Change-Number: 29424
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: Tue, 20 Sep 2022 16:11:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/29425 )
Change subject: lchan: Reset Abis RTP/Osmux config during lchan release
......................................................................
lchan: Reset Abis RTP/Osmux config during lchan release
Otherwise some shared variables used by both Osmux and RTP was left set,
like connect_ip and connect_port, and next time the lchan was selected,
those were already configured even if they didn't come in IPAC CRCX.
This is specially bad if the channel was reused to set up an Osmux call,
since the osmux code path relied on those fields being properly reset
until set by IPAC CRCX.
Change-Id: I414bd0bc801451357bb45b89197a95e51b7c97f1
---
M src/common/lchan.c
1 file changed, 2 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/25/29425/1
diff --git a/src/common/lchan.c b/src/common/lchan.c
index 892d9b7..0402c17 100644
--- a/src/common/lchan.c
+++ b/src/common/lchan.c
@@ -207,6 +207,8 @@
} else if (lchan->abis_ip.osmux.use) {
lchan_osmux_release(lchan);
}
+ /* reset all Abis related config: */
+ memset(&lchan->abis_ip, 0, sizeof(lchan->abis_ip));
/* FIXME: right now we allow creating the rtp_socket even if chan is not
* activated... Once we check for that, we can move this check at the
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/29425
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I414bd0bc801451357bb45b89197a95e51b7c97f1
Gerrit-Change-Number: 29425
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: neels, laforge.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/29422 )
Change subject: add X27 timeout: release lchan that lacks L1 Info
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
Is this behavior defined somewhere in 3GPP specs?
Normally the BTS (not BSC) is responsible for declaring a radio link failure event by sending CONN FAIL IND over the A-bis/RSL. Doesn't Ericsson RBS 6xxx send us such a message? The radio lonk failure is declared "based upon either the error rate on the uplink SACCH(s) or on RXLEV/RXQUAL measurements of the MS" (see 3GPP TS 45.008 sections 5.3). The Connection Failure Criterion is configured via the A-bis/OML.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/29422
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I6fb29315568554c8490ee999fcfd1b77d8245389
Gerrit-Change-Number: 29422
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Tue, 20 Sep 2022 15:18:26 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: laforge.
wbokslag has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/29387 )
Change subject: added support for fill bits and basic link defragmentation (also thanks to SQ5BPF)
......................................................................
Patch Set 3:
(3 comments)
File src/tetra_upper_mac.h:
https://gerrit.osmocom.org/c/osmo-tetra/+/29387/comment/fa659b74_5992edd1
PS3, Line 13: in
> sounds like 'active' could be of type bool? […]
You're right, it's kind of underdocumented. I'll make sure to annotate the fields. Booleans are used nowhere in the osmo-tetra project, so I sticked with what seems to be convention. tetra_mac_state for instance uses a signed int for the is_traffic field. If you want, I can start using the bool type or make the active field and similar fields a uint8_t.
File src/tetra_upper_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/29387/comment/6894bd91_c3ed915d
PS3, Line 44: s
> this introduces a global, static variable. […]
The lower mac allocates a global context structure tetra_cell_data with global pointer tcd. I'd figure that it doesn't belong in that context. We could, however, add an upper mac context (upper_mac_context umc?), which, for now, would only hold the fragslots. Would that be preferable?
Note that passing the context by parameter will not work without changing a lot of unrelated prototypes, as that would imply the lower mac (and burst detector, etcetera) also need to have it. It would not be a bad idea to create a context in tetra-rx that contains the respective states for the burst detector, lower mac, upper mac and possibly layers above, but that would be a significant rework.
https://gerrit.osmocom.org/c/osmo-tetra/+/29387/comment/32214bbc_8fb3be83
PS3, Line 50: fragslots[i].msgb = msgb_alloc(FRAGSLOT_MSGB_SIZE, "fragslot");
> is there a specific reason to pre-allocate lots of message buffers here?
You're right, I could allocate them on demand, whenever a fragmented resource is encountered on a slot. I'll do that in the next patch set
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/29387
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: I41c9438b0b12c2fac9dff1b226eec5b33f30fbb4
Gerrit-Change-Number: 29387
Gerrit-PatchSet: 3
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Tue, 20 Sep 2022 14:01:14 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
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/+/29388 )
Change subject: Support parsing of multiple mac resources in the same timeslot
......................................................................
Patch Set 5:
(1 comment)
File src/lower_mac/tetra_lower_mac.c:
https://gerrit.osmocom.org/c/osmo-tetra/+/29388/comment/e4fd1517_f440d0de
PS4, Line 311: int parsed = 0;
> again the question why those are signed, i.e. […]
In some cases (for instance, when a frame cannot be parsed propery), we cannot determine the size of the MAC PDU. In that case, a -1 will be returned. There are also some cases I haven't explored yet, such as whether an additional PDU can exist after a broadcast. A return value of -1 will lead to the lower mac to not pass any further PDUs to the upper mac for that timeslot.
Offset should be unsigned. Also, it would be more elegant to break inside the loop when a -1 is returned, instead of altering the msg pointers with the negative value. I've pushed a revision with these improvements.
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/29388
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: Ic2956a5f10cffe296b76a290a0d16f45461eb2e7
Gerrit-Change-Number: 29388
Gerrit-PatchSet: 5
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Tue, 20 Sep 2022 13:43:44 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: wbokslag.
Hello Jenkins Builder, fixeria,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-tetra/+/29388
to look at the new patch set (#5).
Change subject: Support parsing of multiple mac resources in the same timeslot
......................................................................
Support parsing of multiple mac resources in the same timeslot
Change-Id: Ic2956a5f10cffe296b76a290a0d16f45461eb2e7
---
M src/lower_mac/tetra_lower_mac.c
M src/tetra_gsmtap.c
M src/tetra_upper_mac.c
3 files changed, 29 insertions(+), 15 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-tetra refs/changes/88/29388/5
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/29388
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: Ic2956a5f10cffe296b76a290a0d16f45461eb2e7
Gerrit-Change-Number: 29388
Gerrit-PatchSet: 5
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-MessageType: newpatchset
Attention is currently required from: pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29420 )
Change subject: add upf/ to test osmo-upf
......................................................................
Patch Set 3:
(3 comments)
File upf/UPF_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29420/comment/e63a1e07_e6f3…
PS1, Line 177: private function f_parse_gtp_action(out GTP_Action ret, charstring str) return boolean {
> CTRL interface? stats?
stats is not a good fit. ctrl is possible but that would need implementing
File upf/expected-results.xml:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29420/comment/dab46f3e_ca16…
PS1, Line 2: <testsuite name='HNB_Tests' tests='0' failures='0' errors='0' skipped='0' inconc='0' time='MASKED'>
> This is still unresolved.
what, i'm certain i edited it...
File upf/expected-results.xml:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29420/comment/a999f114_ec4d…
PS3, Line 2: UPF
here it is
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29420
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: If67819dea785597841f21d8c444cb4866cfde571
Gerrit-Change-Number: 29420
Gerrit-PatchSet: 3
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 20 Sep 2022 13:02:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment