osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

osmo-pcu build error in master
by Holger Freyther 28 Aug '16

28 Aug '16

Hi, it looks like after the rebase done by gerrit something didn't compile anymore. Could someone please have a look at https://gerrit.osmocom.org/#/c/429/ and fix the fall-out in master? thank you holger

1 0

[PATCH][libgtpnl] I can't look tei by tools/gtp-tunnel.c in GTPv1
by junpei yoshino 25 Aug '16

25 Aug '16

Hello I can't look tei by gtp-tunnel in GTPv1. I write patch for libgtpnl. head version $./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2 $./tools/gtp-tunnel list version 1 tei 0/0 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2 fixed version $./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2 $./tools/gtp-tunnel list version 1 tei 65535/65535 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2 diff --git src/gtp-genl.c src/gtp-genl.c index 1e77e06..24a640d 100644 --- src/gtp-genl.c +++ src/gtp-genl.c @@ -119,7 +119,7 @@ static int genl_gtp_validate_cb(const struct nlattr *attr, void *data) const struct nlattr **tb = data; int type = mnl_attr_get_type(attr); - if (mnl_attr_type_valid(attr, CTRL_ATTR_MAX) < 0) + if (mnl_attr_type_valid(attr, GTPA_MAX) < 0) return MNL_CB_OK; switch(type) { -- junpei.yoshino(a)gmail.com

2 1

Re: [EGPRS] Performance results for EGPRS test in Radisys lab
by Saurabh Sharan 12 Aug '16

12 Aug '16

Hello Max, > What about MCS UL? Do you have some statistics which one has been used The uplink tests have been completed for all EGPRS coding scheme (MCS1 - 9) using the ping or TCP download. We have not conducted specific test for throughput estimation in uplink direction till now. Regards Saurabh

2 1

[PATCH 1/2] Remove unused function
by msuraev＠sysmocom.de 08 Aug '16

08 Aug '16

From: Max <msuraev(a)sysmocom.de> --- ggsn/ggsn.c | 1 - gtp/pdp.c | 11 ----------- gtp/pdp.h | 1 - 3 files changed, 13 deletions(-) diff --git a/ggsn/ggsn.c b/ggsn/ggsn.c index 7725016..6866901 100644 --- a/ggsn/ggsn.c +++ b/ggsn/ggsn.c @@ -154,7 +154,6 @@ int create_context_ind(struct pdp_t *pdp) pdp->eua.l = 0; /* TODO: Indicates dynamic IP */ - /* ulcpy(&pdp->qos_neg, &pdp->qos_req, sizeof(pdp->qos_req.v)); */ memcpy(pdp->qos_neg0, pdp->qos_req0, sizeof(pdp->qos_req0)); memcpy(&pdp->pco_neg, &pco, sizeof(pdp->pco_neg)); diff --git a/gtp/pdp.c b/gtp/pdp.c index f0d6adf..f297af9 100644 --- a/gtp/pdp.c +++ b/gtp/pdp.c @@ -370,14 +370,3 @@ void pdp_set_imsi_nsapi(struct pdp_t *pdp, uint64_t teid) pdp->imsi = teid & 0x0fffffffffffffffull; pdp->nsapi = (teid & 0xf000000000000000ull) >> 60; } - -int ulcpy(void *dst, void *src, size_t size) -{ - if (((struct ul255_t *)src)->l <= size) { - ((struct ul255_t *)dst)->l = ((struct ul255_t *)src)->l; - memcpy(((struct ul255_t *)dst)->v, ((struct ul255_t *)src)->v, - ((struct ul255_t *)dst)->l); - return 0; - } else - return EOF; -} diff --git a/gtp/pdp.h b/gtp/pdp.h index 57af8b3..217b1d6 100644 --- a/gtp/pdp.h +++ b/gtp/pdp.h @@ -252,6 +252,5 @@ int pdp_ipget(struct pdp_t **pdp, void* ipif, struct ul66_t *eua); int pdp_ntoeua(struct in_addr *src, struct ul66_t *eua); int pdp_euaton(struct ul66_t *eua, struct in_addr *dst); uint64_t pdp_gettid(uint64_t imsi, uint8_t nsapi); -int ulcpy(void *dst, void *src, size_t size); #endif /* !_PDP_H */ -- 2.9.2

1 1

gerrit openggsn
by Max 08 Aug '16

08 Aug '16

Hi. I've noticed that OpenGGSN is not part of https://gerrit.osmocom.org/#/admin/projects/ Is there plan to move it to gerrit as well or shall I send patches to this list instead? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

[EGPRS] Performance results for EGPRS test in Radisys lab
by Saurabh Sharan 21 Jul '16

21 Jul '16

Hello, We have completed first phase of performance test on EGPRS using iperf tool for short duration runs (1 to 3 hours). Steady throughput of 215 to 223 kbps in Downlink has been achieved under lab conditions over the air test using one Huawei E398 dongle as UE. PCU was configured for 4 PDTCH allocation. Osmo-pcu is based on master branch plus Radisys code changes which are currently under Gerrit review. The execution of test was done on NuRAN 1.0 hardware. Below is a summary of test results Test type MCS DL Duration Throughput(kbps) Achieved Theoretical TCP MCS9 1hour 217 236.8 UDP MCS9 3hour 223 236.8 Regards Saurabh

2 1

PDTCH and PTCCH activation
by Max 21 Jul '16

21 Jul '16

Hi all. I've noticed in osmo-bts logs several messages from L1: 238:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 243:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 246:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 251:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 254:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 260:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 263:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 274:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) Similarly, there are messages related to PTCCH: 257:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 266:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 277:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 288:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) Notice that while PDTCH is activated for both UL and DL, the PTCCH is only activated for DL. As far as I've understood continuous TA procedure I've got to have PTCCH activated in both directions. The problem is that I have troubles locating the code which triggers the activation above. There is l1if_connect_pdch() in osmo-pcu src/sysmo_l1_if.c but it uses GsmL1_PrimId_MphConnectReq while if I understood correctly GsmL1_PrimId_MphActivateReq is necessary for channel activation. There is mph_send_activate_req() in osmo-bts oml.c which uses it. It's called from lchan_act_compl_cb() via sapi_queue_send() which is also in mph_send_activate_req() - I have hard time understanding how this works at all. Do we have this documented somewhere? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 5

signal quality in osmo-pcu
by Max 21 Jul '16

21 Jul '16

Hi. While looking at http://projects.osmocom.org/issues/1616 I've noticed that there seems to be no particular function which get signal quality info from dsp. At least looking at code around ENABLE_DIRECT_PHY have not enlightened me so far. The question is - how exactly signal quality is obtained from dsp (on hw with direct dsp access) to osmo-pcu. There is clear difference between l1if_pdch_req() and pcu_tx_data_req() on TX path but what's the equivalent for RX? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

access bts from pcu's L1 code
by Max 15 Jul '16

15 Jul '16

Hi. While working on https://osmocom.org/issues/1531 I've found that I have to update BTS's configuration (see src/bts.cpp) from osmo-pcu L1 code (see src/osmo-bts-sysmo/sysmo_l1_hw.c). The problem is that the only thing I got in L1 is struct femtol1_hdl which have trx_no but that's about it. Is there a way to get pointer to BTS so I can call bts->set_ta() using trx_no? Or I shall somehow change interface for l1if_fd_cb() - that's where my function with new data is called from? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

Testcase + commit on EDGE patches
by Holger Freyther 12 Jul '16

12 Jul '16

Good Morning all, my real life distraction is mostly gone and I can be more active in developing and reviewing again. From my point of view Sysmocom and me have responded to all Gerrit reviews and we are waiting for the next iteration of the patchset. Before giving a high-level point of view of orders and dependencies I would like to say some words about testing. (Automatic Unit-)testing is crucial. Sometimes it is the easiest way to test a behavior, it allows to hit/test error paths but are hit less frequently. Combined with regular execution of the tests and forbidding to merge code that breaks tests, features that worked once and have a good test will continue to work. It is the key for being able to move forward quickly. For many patches I reviewed test + feature or test + bugfix were in separate commits and then the order is problematic. From my point of view there are only a few "right" combinations. Let me try to explain: Assume some code is doing "if (res) " instead of "if (!res)" and after long debugging we have found that single line (and our code is full of printf now) and it is a path that has not been systematically tested yet. To move forward and create a patchset we should: * Add a test case that triggers the broken behavior. With a xUnit framework we would add an expected failure, with our approach we either capture the broken output, comment the OSMO_ASSERT or revert the OSMO_ASSERT condition. (See libosmocore * Let's say that if is already in code like: if (a) if (b) if (c) if (d) and we would like to re-factor it to be more readable. Then please do the refactoring _before_ applying the bugfix. The test output/result should not change as it is a refactoring. * Finally apply the fix. For bugfixes try to make them as small and clear as possible. Let's say even if you don't like the algorithm used, fix it. As part of the fix the test assertions can be enabled and the output change. The smaller the fix, the better. See libosmocore 6ac70a41ee4cc9f3f286fb6b8f397215590fc2ac for such an example. * If the algorithm is indeed bad now is the time to change it. It should just change the (refactored) method, test output and result should be stable and maybe add more tests as the new code is easier to test. In general my preferred way: New feature => one commit to add feature + test Bugfix => First test, then bugfix+test output/result update thank you holger

2 1

← Newer
1
...
32
33
34
35
36
37
38
...
52
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs