osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

507 discussions

tbf test segfault
by Max 12 Jan '17

12 Jan '17

Hi. The current OsmoPCU master has segfault in tbf test - at least on my machine: Destroying MS object, TLLI = 0x00000000 === start test_tbf_dl_llc_loss === Assert failed !check_element_exists(cnode, cmd->string) command.c:626 backtrace() returned 9 addresses /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element+0xce) [0x7ffff77a5f9e] /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element_ve+0x11) [0x7ffff77a6411] /usr/lib/x86_64-linux-gnu/libosmogb.so.4(gprs_ns_vty_init+0x17) [0x7ffff79c1da7] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x22640) [0x555555576640] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1a73a) [0x55555556e73a] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1697f) [0x55555556a97f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffff67e53f1] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x16eda) [0x55555556aeda] Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff67fc3ea in __GI_abort () at abort.c:89 #2 0x00007ffff77a5fa3 in cmd_make_descvec (descstr=<optimized out>, string=<optimized out>) at command.c:327 #3 install_element (ntype=ntype@entry=1, cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:630 #4 0x00007ffff77a6411 in install_element_ve (cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:637 #5 0x00007ffff79c1da7 in gprs_ns_vty_init (nsi=<optimized out>) at gprs_ns_vty.c:578 #6 0x0000555555576640 in gprs_bssgp_create_and_connect (bts=<optimized out>, local_port=<optimized out>, sgsn_ip=<optimized out>, sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=<optimized out>, bvci=1234, mcc=1, mnc=1, lac=0, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:847 #7 0x000055555556e73a in test_tbf_dl_llc_loss () at tbf/TbfTest.cpp:499 #8 0x000055555556a97f in main (argc=<optimized out>, argv=<optimized out>) at tbf/TbfTest.cpp:2883 Which also seems to be reproducible in jenkins: http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/477/label=linux_amd6… That's odd cause it should have been caught by jenkins way before. Anyone else seeing this? -- 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 3

Contribute to Osmocom and receive a free 3.5G femtocell
by Harald Welte 09 Jan '17

09 Jan '17

Dear all, not everyone might have seen the news item that was posted in late December on our website at http://osmocom.org/news/62 I'm looking forward to receiving your proposal on how you would contribute to the Osmocom project if you were to receive one of those free 3.5G femtocells. Quote of the news item below: ------ So please excuse me to cross-post this over several Osmocom project mailing lists. I know that a number of people have either hacked on femtocells in the past, or at least expressed interest in doing so... Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking on the next level: 3G/3.5G. The key to running your own 3G network is to obtain actual 3G cell hardware -- here is an exciting opportunity to get started: No less than 50 femtocells will be given away for free by sysmocom, one of the main drivers of the Osmocom project. To receive a free 3G femtocell, tell us how you will help the Osmocom project drive 3.5G forward if you had one, before the end of January 2017. This marks the launch of the 3.5G Acceleration Project, backed by the Osmocom community. Join us! Find further details on the 3.5G Acceleration Project and receiving your own 3G femtocell for free at https://sysmocom.de/downloads/accelerate_3g5_cfp.pdf. ------ Best regards and happy hacking, Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[osmo-pcu 0.2.875-b3df5] testsuite: 3 4 failed
by Martin Hauke 07 Jan '17

07 Jan '17

-------------------------------------------------------------------- 3: tbf FAILED (testsuite.at:23) 4: bitcomp FAILED (testsuite.at:30) -------------------------------------------------------------------- os: openSUSE Tumbleweed arch: aarch64 compiler: c++ (SUSE Linux) 6.2.1 20161209 [gcc-6-branch revision 243481] configure options: --disable-static --enable-shared libosmocore: 0.9.6.48-3419 I have attached testsuite.log best regards, Martin

1 0

osmo-pcu: Re: New Defects reported by Coverity Scan for Osmocom
by Neels Hofmeyr 23 Dec '16

23 Dec '16

On Thu, Dec 22, 2016 at 10:15:36AM -0800, scan-admin(a)coverity.com wrote: > *** CID 158969: Null pointer dereferences (FORWARD_NULL) > /source-Osmocom/osmo-pcu/src/gprs_rlcmac_sched.cpp: 131 in sched_select_ctrl_msg(unsigned char, unsigned char, unsigned int, unsigned char, gprs_rlcmac_pdch *, gprs_rlcmac_tbf *, gprs_rlcmac_tbf *, gprs_rlcmac_ul_tbf *)() > 125 struct msgb *msg = NULL; > 126 struct gprs_rlcmac_tbf *tbf = NULL; > 127 struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf }; > 128 > 129 for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) { > 130 tbf = next_list[(pdch->next_ctrl_prio + i) % 3]; > >>> CID 158969: Null pointer dereferences (FORWARD_NULL) > >>> Comparing "tbf" to null implies that "tbf" might be null. > 131 if (!tbf) > 132 continue; > 133 > 134 /* > 135 * Assignments for the same direction have lower precedence, > 136 * because they may kill the TBF when the CONTROL ACK is Even though coverity triggered on the recent addition of tbf->ms()->update_dl_ctrl_msg(); in osmo-pcu da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7, this problem has existed before. This function is handling the tbf pointer improperly. Let's take a look: static struct msgb *sched_select_ctrl_msg( uint8_t trx, uint8_t ts, uint32_t fn, uint8_t block_nr, struct gprs_rlcmac_pdch *pdch, struct gprs_rlcmac_tbf *ul_ass_tbf, struct gprs_rlcmac_tbf *dl_ass_tbf, struct gprs_rlcmac_ul_tbf *ul_ack_tbf) { struct msgb *msg = NULL; struct gprs_rlcmac_tbf *tbf = NULL; This NULL init would only make sense if ARRAY_SIZE(next_list) were zero. Will not happen. struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf }; for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) { tbf = next_list[(pdch->next_ctrl_prio + i) % 3]; if (!tbf) continue; /* * Assignments for the same direction have lower precedence, * because they may kill the TBF when the CONTROL ACK is * received, thus preventing the others from being processed. */ if (tbf == ul_ass_tbf && tbf->direction == GPRS_RLCMAC_DL_TBF) if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ) msg = ul_ass_tbf->create_packet_access_reject(); else msg = ul_ass_tbf->create_ul_ass(fn, ts); else if (tbf == dl_ass_tbf && tbf->direction == GPRS_RLCMAC_UL_TBF) msg = dl_ass_tbf->create_dl_ass(fn, ts); else if (tbf == ul_ack_tbf) msg = ul_ack_tbf->create_ul_ack(fn, ts); if (!msg) { tbf = NULL; If this is not the last for() iteration, setting tbf = NULL makes no sense, it will be set to next_list[..] at the start of the next iteration. If this *is* the last iteration, tbf = NULL makes no sense either, because msg is NULL and tbf will be set to dl_ass_tbf or ul_ass_tbf in the if (!msg) {} case below. continue; } pdch->next_ctrl_prio += 1; pdch->next_ctrl_prio %= 3; break; } if (!msg) { /* * If one of these is left, the response (CONTROL ACK) from the * MS will kill the current TBF, only one of them can be * non-NULL */ if (dl_ass_tbf) { tbf = dl_ass_tbf; msg = dl_ass_tbf->create_dl_ass(fn, ts); } else if (ul_ass_tbf) { tbf = ul_ass_tbf; msg = ul_ass_tbf->create_ul_ass(fn, ts); } } At this point, tbf may be NULL, either from 'if (!tbf) continue;' in the last iteration, or because dl_ass_tbf or ul_ass_tbf were NULL. Below code assumes that tbf is non-NULL and will segfault. Add 'if (!tbf) return NULL' here? /* any message */ if (msg) { tbf->rotate_in_list(); LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling control " "message at RTS for %s (TRX=%d, TS=%d)\n", tbf_name(tbf), trx, ts); /* Updates the dl ctrl msg counter for ms */ tbf->ms()->update_dl_ctrl_msg(); return msg; } /* schedule PACKET PAGING REQUEST */ msg = pdch->packet_paging_request(); if (msg) { LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling paging request " "message at RTS for (TRX=%d, TS=%d)\n", trx, ts); /* Updates the dl ctrl msg counter for ms */ tbf->ms()->update_dl_ctrl_msg(); return msg; } return NULL; } @osmo-pcu tbf folks, please fix this potential segmentation fault ASAP. Thanks! ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

1 1

enum egprs_puncturing_values
by Neels Hofmeyr 16 Dec '16

16 Dec '16

Today I looked at enum egprs_puncturing_values by coincidence: /* * Valid puncturing scheme values * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1 */ enum egprs_puncturing_values { EGPRS_PS_1, EGPRS_PS_2, EGPRS_PS_3, EGPRS_PS_INVALID, }; I notice that TS 44.060 10.4.8a.3.1 defines further items besides PS_1, 2 and 3, and that our EGPRS_PS_INVALID occupies the value the spec defines as "MCS-3/P1". I believe that this is rather unfortunate. [[[ Table 10.4.8a.3.1: Coding and Puncturing Scheme indicator field for Header type 3 bits 4321 First block CPS ---------------------------- 0000 MCS-4/P1 0001 MCS-4/P2 0010 MCS-4/P3 0011 MCS-3/P1 0100 MCS-3/P2 0101 MCS-3/P3 0110 MCS-3/P1 with padding (MCS-8 retransmission) 0111 MCS-3/P2 with padding (MCS-8 retransmission) 1000 MCS-3/P3 with padding (MCS-8 retransmission) 1001 MCS-2/P1 1010 MCS-2/P2 1011 MCS-1/P1 1100 MCS-1/P2 NOTE: All the other values are reserved for future use The bit numbering is relative to the field position. ]]] I would prefer EGPRS_PS_INVALID=-1 (i.e. outside the spec's value range) and the other enum values named appropriately, like EGPRS_MSC4_P1, so that our enum actually reflects the spec as advertised. Is there something I'm missing? These enum values were added in: commit 7a05b039c835868eff34308d861edfeb28d1763b Author: Aravind Sirsikar <arvind.sirsikar(a)radisys.com> Date: Wed Mar 23 18:29:45 2016 +0530 Thanks, ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

2 3

comments on enum egprs_puncturing_values and gprs_rlc_mcs_cps()
by Neels Hofmeyr 16 Dec '16

16 Dec '16

Hi, in the wake of https://gerrit.osmocom.org/1411 I have some more comments on the code that seem to large for the gerrit edit field. I said in that patch comment that gprs_rlc_mcs_cps() must check that it isn't using INVALID enum values in its bitfield calculations. Furthermore: The bit fields are obtained by modulo calculation on enum values. This seems unnecessarily complex and error prone, it is hard to figure out for a reader. The relation is quite direct though, e.g. for EGPRS_MAX_PS_NUM_2 it means that PS_1 and PS_3 mean + 0, PS_2 means + 1. I wish that were easier to see. It would be good to prepare that above the switch() and use it below instead of duplicating the same calculation numerous times. Thirdly, for enum egprs_puncturing_values, the comment refers to TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1. When reading the first time, I saw table 10.4.8a.3.1 reflecting the names found in the table: PS1, PS2 and PS3. And it appeared that there are values missing. Typically, when we place a spec reference on an enum in Osmocom code, it means that this enum *exactly* represents the given table. This enum, however, is "merely" an internal indicator, later translated into the table's bit values. The enum definitions should have a comment sort of like "Puncturing scheme values. See gprs_rlc_mcs_cps()" without TS table references, and TS refs should be with that function. It's also not helpful to place references to two more tables in the comment: the reader is left guessing what the exact relation is. If more than one TS table is involved, the comment should explain the relation. Cosmetic: the switch() statement in that function has line breaking that doesn't match Osmocom coding style, making it even harder to read. These are things we missed when accepting these changes. It would be nice to get them fixed at some point. Thanks! ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

1 0

RFC: OsmoDevCon 2017 planning
by Harald Welte 10 Dec '16

10 Dec '16

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] >From 2012 to 2016 we were running a series of small, invitation-only Osmocom Developer Conferences. Access was intentionally restricted to those community members who have demonstrated an existing track record of contribution to any of the projects under the Osmocom umbrella. This format of a small, tightly knit group of about 20 people has been successful over the years, and I have received a lot of positive feedback from past participants. On the other hand, the Osmocom project has grown in scope and diversity, and some of those projects don't have all that much relationship to each other - except being started by people from within the same group. There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at some point LTE) protocols which is attracting a lot of professional users. And then there's pure community projects like rtl-sdr, OsmocomBB, OsmocomGMR and many other efforts. Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow "standing out" of the othe projects in the context of having a wider user bsae, and in that user base also primarily commercial users. So I'd like to start a discussion on how to possibly change the event format to accomodate the various interests and parties. I definitely don't want to loose the "annual meeting of old friends" atmosphere, while at the same time also opening up to other interested parties. One idea would be to keep OsmoDevCon as-is and have a separate event where non-contributing/developing users / sysadmins / system integrators could also be attending. Another idea would be to split into a 'user day' and 'developer days' format. This is something the netfilter developer workshops have been using for many years, and from my limited insight quite successfully so. The "user day" is more like a traditional tech conference, with a large auditorium and talks oriented towards users / sysadmins / integrators of the software. The "developer days" are the invitation-only part, for known contributing developers only, similar to what we have at OsmoDevCon. Having both events (or both parts of an event) back-to-back has the advantage that a large number of potential speakers for the 'user day' are already present, and they don't have to travel yet another time. One could even structure it further and say we have one user day, one public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon classic', maybe reduced from 4 days to 3 or even 2 days only? What is the general opinion about this? Are there people lurking on this list who would be interested in attending a public 'user day' or even 'developer day' about the Osmocom cellular projects, with presentations and workshops around topics such as running Osmocom based cellular networks? In terms of when/where, I would suggest to keep the tradition of April in Berlin/Germany. But I'm of course very happy if somebody wants to host it some place else... Regards, and looking forward to meeting you [again] in 2017, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

P*CH activation
by Max 02 Nov '16

02 Nov '16

HI. Pardon the cross-posting, I'm not sure where this question really belongs. I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what got to be activated both in DL and UL directions. Right now it's PDTCH (UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are commented out. Yet I see code dealing with PACCH in osmo-pcu and corresponding log messages. So the question is - how does this works? The PACCH seems to be used so it's somehow activated but apparently not the same way as PDTCH. -- 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

Load balancing issue on Multi-TRX configuration
by Aravind Sirsikar 31 Oct '16

31 Oct '16

Hello All, We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done Across the TRXs. Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue. Thanks and Regards, Aravind Sirsikar

3 2

Profiling data of decoding EPDAN compressed bitmap
by Prasad Kaup 29 Oct '16

29 Oct '16

Hello All, We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN. >From the results , we see that performance is better in Tree based decoding (Version2 as given below ) Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode ) Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> ) A sample bitmap taken from a real mobile log is used for the test. Host execution: Time taken to decode (micro seconds) Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9 Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2 Target execution: Time taken to decode (micro seconds) Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353 Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8 Regards Prasad

4 17

← Newer
1
...
28
29
30
31
32
33
34
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs