OpenBSC

openbsc@lists.osmocom.org

4 participants
4156 discussions

by Neels Hofmeyr

Hi all, I'd like to share my odd? interesting? unnerving? experience today. All I wanted to do is quickly check something (gerrit #713) on sysmobts, but I faced a series of problems. First some sysmobts related problems, later two problems entirely unrelated to osmocom... (*) My sysmobts SDK no longer works: libosmo-abis now requires libortp >= 0.22.0, but the SDK I have used so far doesn't have that: poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160323112523.sh (I didn't go through it in this sequence, but tried these things:) a) tried to build a more recent libortp into the installed SDK. It goes fine up to a point. It takes a bit of work to find and fetch all the repositories that are required: git://git.linphone.org/bcunit.git git://git.linphone.org/bctoolbox.git git://git.linphone.org/ortp.git but sadly, bctoolbox wants libpolarssl aka mbedtls git@github.com:ARMmbed/mbedtls.git -- which has no automake/autoconf, only a plain Makefile! It also has cmake and others, but so far I only know how to tell the ./configure script to cross-compile and install into the SDK, so I kind of gave up on figuring out cmake for that, for now. b) just reverted the libortp version bumping commit in libosmo-abis (15d9b7929d449e4138bcb003c614035bceadc3d1) Everything compiles and works out, but alas, I get constant very weird distortion/blip-tones/hickups on the voice channels, a bit of voice still audible but definitely some bad codec problem. A regression? Is it related to libortp? This happens both for a TS config of TCH/H and TCH/F. c) tried fetching a new SDK from 201310-testing/sdk: poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160910200558.sh This has the same problem with too old libortp. Again I revert the libortp version bump from libosmo-abis. Same results as above: badly broken voice. d) tried a new 1.5.4 SDK from 201310-nightly/sdk: poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.4-20161004010024.sh Here libosmo-abis is fine with the libortp it finds, so far so good. Sadly, this doesn't even do hickuped voice, only low noise on both ends. So I decided to go back to the SDK that worked for me last time to bisect. I will post another mail in case I found a regression. (*) For half a minute there I wondered why GPRS wasn't working until I remembered our two-phase-access aka WAIT_ASSIGN problem in osmo-pcu and reverted f1a7b8fc. With that, GPRS works fine with all of the above. phew ;) (*) Entirely unrelated to osmocom: I launch my CN programs from a script that launches multiple terminals. I happen to use rxvt-unicode for that and always have for a year. Turns out this time urxvt strips the LD_LIBRARY_PATH when it is invoked. I still don't know how this changed, but when I drop the suid that I find for unknown reasons sitting on the urxvt binary's group ('chmod g-s /usr/bin/urxvt'), it lets the LD_LIBRARY_PATH be, and the binaries run. How did this change from the last time I ran my CN scripts?? No idea. (*) Same with sudo: LD_LIBRARY_PATH now all of a sudden gets stripped during my sudo ggsn -f -c ggsn.conf invocation. I use sudo for ggsn to allow establishing tunnels. Again I didn't change anything about my scripts, just today it doesn't find the libraries in /usr/local/lib anymore. I have to manually add it like sudo LD_LIBRARY_PATH=/usr/local/lib ggsn ... but then sudo tells me I'm not allowed to set the env. After searching around, I add 'SETENV:' to my sudoers file: neels ALL= NOPASSWD:SETENV: /usr/local/bin/ggsn * This time ggsn starts again like it always used to. How did this change from last time I ran ggsn this way?? No idea at all. So my quick test took a bit longer than expected (hasn't started), and the night has progressed at an alarming rate... I'll write again when I found anything on the broken voice. ~Neels -- - 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

8 years, 9 months

coverity for osmocom projects

by Neels Hofmeyr

Today, I've taken a quick look at the coverity stuff, because so far I've only seen coverity reports on the Iu code. I see now that actually all of the other osmocom components are also tested by coverity. So far I'm only seeing the "Osmocom" coverity project, which contains only the iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'. The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc: https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo I see there are "add me to project" buttons e.g. here https://scan.coverity.com/projects/libosmocore so I'm trying that now. Wouldn't it make sense to redirect all the coverity reports to a mailing list? Probably best would be a new mailing list, to avoid noise on openbsc@, like the gerrit-log@ list. Are these coverity reports a matter of secrecy, to avoid publishing security holes before we fixed them, in which case the coverity mailing list should be invite-only? ~Neels

8 years, 9 months

Query on run time control of network with VTY

by Dhananjay kumar

Hi, While ruining osmo-bts and osmo-trx via VTY we tried to change parameter like Band ,ARFCN MS max power. We observed that once ARFCN is changed on VTY TRX does not switch to new ARFCN. Same behavior has been observed with Band and MS-Max-Power and RF-Locked 0/1 parameter. Request someone who is running osmo-stack has controlled network ,please reply or any document/pointer is appreciated. BR Dhananjay

8 years, 9 months

osmo-sip-connector issue

by Anonim Stefan

Hi, I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as in the attached trace. The connector replies with 0.0.0.0 RTP IP and 0/unknown codec and then ends the call. I am seeing the following log: " Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:334 call(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104 Unknown ptmsg(0). call broken Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:312 leg(5001) rtp connect failed Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245 Ending leg(0x91ec30) in con Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:304 leg(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186 leg(0x91ec30) got bye, releasing. " This issue happens *after* *recently* *updated* *packages* to: " ii osmocom-nitb 0.15.1.20160922 amd64 GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR ii osmo-sip-connector 1.20160922 amd64 MNCC to SIP bridge for osmo-nitb " On the osmo-nitb side I am seeing logs [1]. I suspect a bug in the osmo-sip-connector code. Can someone confirm this? [1] http://pastebin.com/giG0HHha

8 years, 9 months

Moving from trac to a single redmine

by Holger Freyther

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

8 years, 9 months

RFC: use AddressSanitizer by default in gerrit

by Max

Hi. When gerrit check the patch it only cares about "make check" result. There's also a way to use AddressSanitizer for a given branch via http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ I've just sent patch which fixes latest missing bit in libosmocore which enables running AddressSanitizer with "make check" - see gerrit #863. When this is merged we can enable AddressSanitizer for the "make check" used by gerrit to verify patch submissions. What do you think? Note: we can't enable it yet for OpenBSC but all the libraries seems to be fine. -- 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

8 years, 9 months

libosmo-abis question

by Max

Hi. Coverity have noticed weird piece of code in libosmo-abis osmo_rtp_socket_fdreg(): ... rs->rtp_bfd.when = rs->rtcp_bfd.when = BSC_FD_READ; rs->rtp_bfd.when = rs->rtcp_bfd.when = 0; ... It's on the border between 2 commits so it's likely merge artifact. Which value is the right one? Or should it be rtcp_bfd? -- 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

8 years, 9 months

Re: New Defects reported by Coverity Scan for Osmocom

by Neels Hofmeyr

On Mon, Sep 19, 2016 at 06:02:45AM -0700, scan-admin(a)coverity.com wrote: > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 5 new defect(s) introduced to Osmocom found with Coverity Scan. > 6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 5 of 5 defect(s) > > > ** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > > > ________________________________________________________________________________________________________ > *** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > 267 > 268 response_len = > 269 gprs_llc_process_xid_ind(gph->data, gph->data_len, > 270 response, sizeof(response), > 271 lle); > 272 xid = msgb_put(resp, response_len); > >>> CID 148210: Error handling issues (NEGATIVE_RETURNS) > >>> "response_len" is passed to a parameter that cannot be negative. @dexter ^ check that response_len > 0 > 273 memcpy(xid, response, response_len); > 274 > 275 gprs_llc_tx_xid(lle, resp, 0); > 276 } else { > 277 LOGP(DLLC, LOGL_NOTICE, > 278 "Received XID confirmation from phone.\n"); > > ** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > > > ________________________________________________________________________________________________________ > *** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > 408 > 409 /* Incremental migration waterfall */ > 410 switch (db_rev) { > 411 case 2: > 412 if (update_db_revision_2()) > 413 goto error; > >>> CID 148209: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. add: /* fall through */ ? > 414 case 3: > 415 if (update_db_revision_3()) > 416 goto error; > 417 > 418 /* The end of waterfall */ > 419 break; > > ** CID 148208: Control flow issues (DEADCODE) > /source-iuh/openbsc/openbsc/src/osmo-bsc/osmo_bsc_ctrl.c: 408 in set_net_timezone() > > > ________________________________________________________________________________________________________ > *** CID 148208: Control flow issues (DEADCODE) > >>> CID 148208: Control flow issues (DEADCODE) > >>> Execution cannot reach the expression "0L" inside this statement: "tz->hr = (hourstr ? atol(ho...". The website has more detail: " > static int set_net_timezone(struct ctrl_cmd *cmd, void *data) > 386{ > 387 char *saveptr, *hourstr, *minstr, *dststr, *tmp = 0; > 388 int override; > 389 struct gsm_network *net = (struct gsm_network*)cmd->node; > 390 > 391 tmp = talloc_strdup(cmd, cmd->value); > 392 if (!tmp) > 393 goto oom; > 394 > 395 hourstr = strtok_r(tmp, ",", &saveptr); > 396 minstr = strtok_r(NULL, ",", &saveptr); > 397 dststr = strtok_r(NULL, ",", &saveptr); > 398 > 399 override = 0; > 400 cond_notnull: Condition hourstr != NULL, taking true branch. Now the value of hourstr is not NULL. > 401 if (hourstr != NULL) > 402 override = strcasecmp(hourstr, "off") != 0; > 403 > 404 struct gsm_tz *tz = &net->tz; > 405 tz->override = override; > 406 > 407 if (override) { notnull: At condition hourstr, the value of hourstr cannot be NULL. dead_error_condition: The condition hourstr must be true. CID 148208 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution cannot reach the expression 0L inside this statement: tz->hr = (hourstr ? atol(ho.... > 408 tz->hr = hourstr ? atol(hourstr) : 0; > 409 tz->mn = minstr ? atol(minstr) : 0; > 410 tz->dst = dststr ? atol(dststr) : 0; > 411 } > 412 > 413 talloc_free(tmp); > 414 tmp = NULL; > 415 > 416 return get_net_timezone(cmd, data); > 417 > 418oom: > 419 cmd->reply = "OOM"; > 420 return CTRL_CMD_ERROR; > 421} " So override == 0 by default. override will only be set if hourstr != NULL. So inside 'if (override)', hourstr will always be != NULL, and the first '?' is superfluous. This exists since the function was added in 2013. > ________________________________________________________________________________________________________ > *** CID 148207: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libbsc/abis_rsl.c: 415 in channel_mode_from_lchan() > 409 default: > 410 LOGP(DRSL, LOGL_ERROR, > 411 "unsupported lchan->csd_mode %u\n", > 412 lchan->csd_mode); > 413 return -EINVAL; > 414 } > >>> CID 148207: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. This missing 'break' is an error introduced in e4227988665cae6e44fc0f77c2463aae759f15ca "RSL: Add basic support for CSD transparent mode" > 415 default: > 416 LOGP(DRSL, LOGL_ERROR, > 417 "unsupported lchan->tch_mode %u\n", > 418 lchan->tch_mode); > 419 return -EINVAL; > 420 } > > ** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > > > ________________________________________________________________________________________________________ > *** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > 554 /* 10.5.5.7: */ > 555 acreq->force_stby = force_standby; > 556 /* 3GPP TS 24.008 10.5.5.19: */ > 557 if (RAND_bytes(&rbyte, 1) != 1) { > 558 LOGP(DMM, LOGL_NOTICE, "RAND_bytes failed for A&C ref, falling " > 559 "back to rand()\n"); > >>> CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > >>> "rand" should not be used for security related applications, as linear congruential algorithms are too easy to break. well spotted, coverity :) Do they actually analyse whether that it is security related code? rand() is only the fallback for RAND_bytes(). ~Neels > 560 acreq->ac_ref_nr = rand(); > 561 } else > 562 acreq->ac_ref_nr = rbyte; > 563 mm->ac_ref_nr_used = acreq->ac_ref_nr; > 564 > 565 /* Only if authentication is requested we need to set RAND + CKSN */ > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… > > To manage Coverity Scan email notifications for "nhofmeyr(a)sysmocom.de", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… > -- - 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

8 years, 9 months

Loopback call on osmo-bts

by Dhananjay kumar

Hi all, I am trying to make loopback call on osmo-bts VTY interface using ettus B200/B210 hw. in vty.c file i can see options available for loopback call , but loopback call is not started once triggered from osmobts VTY interface. Can some one help ? DEFUN(bts_t_t_l_loopback, bts_t_t_l_loopback_cmd, "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", BTS_T_T_L_STR "Set loopback\n") -- Thanks & Regards Dhananjay 9686184214 Luck is what happens when preparation meets opportunity.

8 years, 9 months

Query regarding Loopback support in Osmobts

by Mayuri Tendulkar

Hi We are looking for a feature at L1 Physical layer loopback in Osmo-bts-trx. Is this feature available and how it can be tested? Regards Mayuri

8 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC