- OpenBSC - lists.osmocom.org

coverity for osmocom projects
by Neels Hofmeyr 03 Oct '16

03 Oct '16

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

3 6

Query on run time control of network with VTY
by Dhananjay kumar 01 Oct '16

01 Oct '16

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

4 6

osmo-sip-connector issue
by Anonim Stefan 30 Sep '16

30 Sep '16

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

2 5

Moving from trac to a single redmine
by Holger Freyther 25 Sep '16

25 Sep '16

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

6 15

RFC: use AddressSanitizer by default in gerrit
by Max 20 Sep '16

20 Sep '16

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

1 0

libosmo-abis question
by Max 20 Sep '16

20 Sep '16

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

2 1

Re: New Defects reported by Coverity Scan for Osmocom
by Neels Hofmeyr 19 Sep '16

19 Sep '16

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

1 0

Loopback call on osmo-bts
by Dhananjay kumar 16 Sep '16

16 Sep '16

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.

1 0

Query regarding Loopback support in Osmobts
by Mayuri Tendulkar 15 Sep '16

15 Sep '16

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

1 0

GSM 05.03 code re-licensing
by Vadim Yanitskiy 14 Sep '16

14 Sep '16

Hello everyone! Right now I am moving some code from OsmoBTS to libosmocore, exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a licensing conflict, because this code licensed under AGPLv3+, but libosmocore code is GPLv2+. So, this is why I am contacting all authors/copyright holders. The question is: does everyone agree to re-license the code under GPLv2-or-later and move it code to libosmocore? Thanks in advance! With best regards, Vadim Yanitskiy.

4 3