From nhofmeyr at sysmocom.de  Sun Oct  1 22:18:10 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 2 Oct 2017 00:18:10 +0200
Subject: Osmo_IuH_building_problems
In-Reply-To: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
Message-ID: <20171001221810.GB2028@my.box>

On Fri, Sep 29, 2017 at 07:09:44AM +0000, Popovic Goran wrote:
> The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

For the record, it is more than pointless to send disclaimers like this to open
mailing lists. These mails will obviously be sent to all subscribers as well as
be publicly available in our mail archives. We will not delete the e-mail.

If possible, please don't send void legalese to our public mailing lists.
Thanks!

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171002/13efc386/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Oct  1 22:27:30 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 2 Oct 2017 00:27:30 +0200
Subject: Osmo_IuH_building_problems
In-Reply-To: <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
 <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
Message-ID: <20171001222730.GC2028@my.box>

On Fri, Sep 29, 2017 at 03:11:23PM +0000, Popovic Goran wrote:
> I tried this time from the scratch with
> 
> git://git.osmocom.org/osmo-dev

I agree with Holger. I added some hints to the readme file there:

note that the makefiles by default install to /usr/local/*,
so if your system doesn't have this by default, you should probably add

  export LD_LIBRARY_PATH="/usr/local/lib"

and

  export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

to your environment. To use the installed binaries after installation, also

  export PATH="$PATH:/usr/local/bin"

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171002/4201ce50/attachment.bin>

From alexander.chemeris at gmail.com  Mon Oct  2 10:19:35 2017
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 2 Oct 2017 13:19:35 +0300
Subject: branches in openbsc.git
In-Reply-To: <20170927222231.GA25140@my.box>
References: <20170927222231.GA25140@my.box>
Message-ID: <CABmJbFUUr6989OxWgp1zxbGLKajAKQAJM6Xn0h_RK6V0+8KYzA@mail.gmail.com>

Hi Neels,

I would appreciate if the 'fairwaves/master-rebase' branch is migrated:

I assume that the old repo will continue to exist, and we'll be able
to refer to it if we need / forget something?

On Thu, Sep 28, 2017 at 1:22 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> another call for anyone aware of important branches on openbsc.git to please
> name them, so that they can be migrated to the new repositories.
> But foremost, please name them, thanks!
>
> ~N



-- 
Regards,
Alexander Chemeris.
CTO/Founder, Fairwaves, Inc.
https://fairwaves.co


From nhofmeyr at sysmocom.de  Mon Oct  2 11:35:11 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 2 Oct 2017 13:35:11 +0200
Subject: git repository delays
Message-ID: <20171002113511.GA2975@my.box>

Hi all,

for a while now I notice that it can take really long to just do a 'git fetch'
of few kilobytes volume (or none at all) on a couple of repositories. I would
expect a rapid trickle through all, most to be finished within half a second,
but sometimes it takes three full minutes to bump 21 git repositories. These
are all from the gerrit ssh URL.

Does anyone know what causes this delay? Would it be gerrit processing time,
server load or network congestion? I haven't taken a closer look yet...

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171002/85b67da6/attachment.bin>

From laforge at gnumonks.org  Mon Oct  2 15:37:27 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 2 Oct 2017 23:37:27 +0800
Subject: branches in openbsc.git
In-Reply-To: <CABmJbFUUr6989OxWgp1zxbGLKajAKQAJM6Xn0h_RK6V0+8KYzA@mail.gmail.com>
References: <20170927222231.GA25140@my.box>
 <CABmJbFUUr6989OxWgp1zxbGLKajAKQAJM6Xn0h_RK6V0+8KYzA@mail.gmail.com>
Message-ID: <20171002153727.vgnbgpmdy4fffo4n@nataraja>

Hi Alexander,

On Mon, Oct 02, 2017 at 01:19:35PM +0300, Alexander Chemeris wrote:

> I assume that the old repo will continue to exist, and we'll be able
> to refer to it if we need / forget something?

yes, it's mainly to make sure we don't forget about branches that we
do want to merge (to the new split repositories).

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Tue Oct  3 00:49:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 3 Oct 2017 08:49:04 +0800
Subject: RFC: CTRL interface and rate_ctr group names
Message-ID: <20171003004904.tiy6kwvem5akimge@nataraja>

Dear all,

this is a post about https://osmocom.org/issues/2362 in which I try to
resolve the "naming fuck-up" regarding the automatic export of rate_ctr.

In short:
* CTRL uses '.' to separate individual elements/nodes of the command
* a lot of rate_ctr groups we use so far use '.' in their group names
  (e.g. 'bssgp.bss_ctx') and counter names (e.g. 'tx.bytes')
* This makes the counters un-exportable via CTRL

I have a libosmocore patch that verifies the validity of counter names
(to not contain spaces or dots) at registration time.  This way we can
catch any application with erroneous behaviour.

However, this causes the following problem: New libosmocore versions
will make old apps crash or at least fail to have propre counters, as
their names are wrong :(

Also, I don't like to replace all '.' in the counter with '_', as in
seen in the example of 'bssgp.bss_ctx' there is a semantic difference.
'bssgp.' is denoted to indicate the code module from which the counter
is, and 'bss_ctx' denotes the specific object whose counters we refer
to.  Manually replacing this with 'bssgp_bss_ctx' is ugly.

One alternative would be to replace '.' with ':' or '/', which are not
characters with a special functoin in the CTRL syntax.  This could be
even done automatically at counter registration time, simply replace all
occurrences of '.' with ':' (and log a warning as a reminder to fix the
code?).

I prefer that more, but the question is which characters should be
reserved for CTRL syntactic purpoess, and which are free to use by the
applications to name elements of the CTRL string/node.

Any input to this?  I personally would go for ':'.  As CTRL is very
loosely modelled after sysfs, ':' also occurs frequently in sysfs names
such as '/sys/bus/usb/devices/1-3:2.0'

So we'd keep the '.' as path/node separator, and we use ':' as separator
inside counter (and possibly other) names, which is opaque to CTRL.

Opinions?

Should we further restrict the CTRL interface strings (and those of
systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
of special characters such as ":-_@" but prevent any non-printable chars
or special chars like "{|}()~[]\^`'?<>=;/+*&%$#!"?  I would support such
a motion.  We could even make it more general and use that for all our
identifier strings and have a general validation function that all code
modules call whenever validating a string identifier used, such as e.g.
osmo_fsm names, etc.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From anindya.s at toshniwalcontrols.com  Tue Oct  3 07:24:56 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 3 Oct 2017 12:54:56 +0530
Subject: Integrating openBSC with 3rd party MSC
Message-ID: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>

Hello,

 I need some help regarding configuration of 3rd party msc to the openbsc.
I have seen the msc command in the openBSC terminal which I entered and
felt like a profile creation for MSC's. But I got little confused doing it,
can anyone provide me any documentation regarding basic connection that I
need to do in order to get a up and running GSM network.

Thanks
Anindya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171003/f811b99d/attachment.htm>

From ron.menez at entropysolution.com  Tue Oct  3 09:21:12 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 3 Oct 2017 09:21:12 +0000
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <7D45202D-BF97-46C6-8138-F94FEE67077D@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
 <20170918115049.GA1618@my.box>
 <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>
 <20170920174514.GE3835@my.box>
 <7D45202D-BF97-46C6-8138-F94FEE67077D@entropysolution.com>
Message-ID: <2387331B-DB7E-4460-9667-271D99F69FFD@entropysolution.com>

Hi Neels,

We tried to compile the osmo-bsc from git.osmocom.org<http://git.osmocom.org>. But we still have the same error until now:

checking for LIBOSMOLEGACYMGCP... no
configure: error: Package requirements (libosmo-legacy-mgcp >= 0.0.1) were not met:

No package 'libosmo-legacy-mgcp' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBOSMOLEGACYMGCP_CFLAGS
and LIBOSMOLEGACYMGCP_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

We are using Ubuntu 10.04 and the directory where we compiled the osmo-bsc is in ?/usr/local/osmo-bsc?.

We also did the following:

 export LD_LIBRARY_PATH="/usr/local/lib"

 export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

But we still have the same error.

We also run the ?git log? to confirm the committed version:

commit 918cfeb7870b118842c710dd88226ac70529fb5e
Author: Max <msuraev at sysmocom.de<mailto:msuraev at sysmocom.de>>
Date:   Fri Sep 29 14:33:35 2017 +0200

    Fix repo split aftermath

    * remove checks for non-existent tests
    * always enable bsc and nat-trie tests because both are built
      unconditionally
    * enable gsm0408 test which was removed by mistake
    * adjust gsm0408 test output to remove SMS-related results

    Change-Id: I73ad079a6333ba56e73b7c4d1d0e9c8255c2a03b
    Related: OS#2257

commit 14f9772f146dd8890bfbe15eb030d7fedbeb6ab8
Author: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
Date:   Sun Oct 1 11:09:47 2017 +0800

    gsm0408_test: Verify that BA-IND is 0 in SI2xxx and 1 in SI5xxx

    This adds a test case to explicitly verify the BA-IND is as expected
    by the behaviour introduced in Change-Id I1cd0dc51026dcd0e508e63eea4e333e6b184787a

    Related: OS#2525
    Change-Id: I3e5b260af97ce96a221e4d51f6c1b41d58817a59

commit aa70d9d828a8163b8cf40c86de11694afeb05f65
Author: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
Date:   Sat Sep 30 09:22:30 2017 +0800

    Make sure BA-IND in all SI2xxx is '0' and in all SI5xxx is '1'

    In masurement reports sent by the MS, this can then be used to correlate
    if a given measurement report was in response to a BCCH/neighbor list
    received on BCCH (SI2xxx) or on dowlink SACCH (SI5xxx).

    Closes: OS#2525
    Change-Id: I1cd0dc51026dcd0e508e63eea4e333e6b184787a

commit d6a52e993d428b47cf6e8d3280b787e07dc9b855
Author: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
Date:   Sat Sep 30 09:22:14 2017 +0800

    libbsc: document arguments of generate_bcch_chan_list()

    Change-Id: I5afc6e6a5a1d6b6a8ee73fdb60cc28074cf8585b

Is the failures for the git version still existing, or we only have an issue in our OS installation?

TIA.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>






On Sep 21, 2017, at 2:00 PM, Ron <ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>> wrote:

Hi Neels,

Thank you for the info shared.

If we able to develop something that can be good for the community, we?ll share it as well.

As of now, the osmo-bsc for Ubuntu is not yet ready from the nightly package. We?ll wait till everything is ok.

And if the git repo is already ready for download, we?ll then start immediately.

We?ll also check the "top-level makefile? project and see what we can do from there.

Thank you.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>




On Sep 21, 2017, at 1:45 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote:

On Tue, Sep 19, 2017 at 08:34:16AM +0000, Ron wrote:
But we are using Ubuntu 16.10 as our OS.

We do build packages for Ubuntu 16.10.
https://build.opensuse.org/project/show/network:osmocom:nightly (old osmo-nitb)
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly (new M3UA)

The failures still need resolving, but otherwise it's there.

BTW, we are hoping to have the git version instead of the nightly package. We are also exploring in doing some development on our side.
Is there an available git version of osmo-bsc, osmo-stp, osmo-msc and osmo-hlr that we can download?

See http://git.osmocom.org<http://git.osmocom.org/>
To contribute, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

I have recently published a "top-level makefile" project to build osmocom 2G
and 3G, which might be helpful to build everything with just a few commands:

 git clone git://git.osmocom.org/osmo-dev
 less osmo-dev/README

~N

--
- Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171003/78cb0c84/attachment.htm>

From nhofmeyr at sysmocom.de  Tue Oct  3 22:48:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 00:48:48 +0200
Subject: RFC: CTRL interface and rate_ctr group names
In-Reply-To: <20171003004904.tiy6kwvem5akimge@nataraja>
References: <20171003004904.tiy6kwvem5akimge@nataraja>
Message-ID: <20171003224848.GD3156@my.box>

On Tue, Oct 03, 2017 at 08:49:04AM +0800, Harald Welte wrote:
> * CTRL uses '.' to separate individual elements/nodes of the command
> * a lot of rate_ctr groups we use so far use '.' in their group names
>   (e.g. 'bssgp.bss_ctx') and counter names (e.g. 'tx.bytes')
> * This makes the counters un-exportable via CTRL

I'm thinking, we could make the current rate_ctr_group_alloc() replace '.' with
':' automatically to fix all older and current builds' CTRL for rate_ctr. At
the same time we can deprecate rarate_ctr_group_alloc() and provide
rate_ctr_group_alloc2(), which then aborts the program when rate_ctr names
don't adhere to strict identifier rules. Thus we get a compile-time warning for
applications that haven't reviewed correctness of rate_ctr naming
("rate_ctr_group_alloc() is deprecated...") and once an application has moved
on we make sure no new non-compliant names are introduced.  However, newly
introduced names will get checked only during run time.

Another addition could be a script like
verify_value_string_arrays_are_terminated.py but for struct rate_ctr_group_desc
arrays' identifier adherence, to verify even before compilation.

> Should we further restrict the CTRL interface strings (and those of
> systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
> of special characters such as ":-_@" but prevent any non-printable chars

For identifier validation, we should probably include that identifiers must not
start with a number.

I think we could also include ",~+^"

as pseudocode:

  valid = isalpha(str[0]) && each(str[1..len] as c){ isalnum(c) || c in ":-_@,~+^" }


Losely related is the OsmoHLR idea for CTRL interface to use names like

  SET subscriber.by-imsi.1234567898765.ps-enabled 1

where a CTRL identifier name is used for inputting an IMSI string. If we do the
same identifier checking during incoming CTRL interface commands, we would
forbid the IMSI name because it starts with a number.

Thinking now that we could go for something like

  subscriber.by-imsi=1234567898765.ps-enabled 1
or maybe rather
  subscriber.by-imsi-1234567898765.ps-enabled 1

I would have liked to use existing CTRL parsing to separate out the IMSI number
without added char parsing... but it's not too hard to add a ctrl_cmd_lookup()
that checks starts_with('by-imsi-') and then takes &str[8].

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/45f32c4d/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct  3 23:05:57 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 01:05:57 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
Message-ID: <20171003230557.GE3156@my.box>

On Tue, Oct 03, 2017 at 12:54:56PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
>  I need some help regarding configuration of 3rd party msc to the openbsc.

The binary you are looking at would be osmo-bsc. During the current code
refactoring we have two versions, one (old) osmo-bsc from openbsc.git using
SCCPlite, and one (new) osmo-bsc from osmo-bsc.git using SCCP/M3UA.

There is no proper documentation for the new SCCP/M3UA yet, but you can examine
configuration in the osmo-gsm-tester "aoip_*" runs on
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/

The old SCCPlite osmo-bsc should be documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Manuals

Let me plug again that connecting osmo-bsc with a third-party MSC is likely to
be non-trivial, and you may greatly benefit from professional support by one of
the companies proficient in the Osmocom code base. Purchasing support is also a
way of supporting ongoing development of the open Osmocom code base; e.g. the
mail you are receiving now is made possible by my employer, sysmocom.de.

~N

-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/f89e13ab/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct  3 23:16:52 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 01:16:52 +0200
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <2387331B-DB7E-4460-9667-271D99F69FFD@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
 <20170918115049.GA1618@my.box>
 <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>
 <20170920174514.GE3835@my.box>
 <7D45202D-BF97-46C6-8138-F94FEE67077D@entropysolution.com>
 <2387331B-DB7E-4460-9667-271D99F69FFD@entropysolution.com>
Message-ID: <20171003231652.GF3156@my.box>

Hi again,

> checking for LIBOSMOLEGACYMGCP... no
> configure: error: Package requirements (libosmo-legacy-mgcp >= 0.0.1) were not met:

Maybe you have not installed osmo-mgw.git, where libosmo-legacy-mgcp comes
from?

We are aware that the current state of wiki and manuals does not reflect the
new repositories at all yet, working on it. Noting that a list of what is found
where and depends on what would be good.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/81818365/attachment.bin>

From ron.menez at entropysolution.com  Wed Oct  4 09:12:10 2017
From: ron.menez at entropysolution.com (Ron)
Date: Wed, 4 Oct 2017 09:12:10 +0000
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <20171003231652.GF3156@my.box>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
 <20170918115049.GA1618@my.box>
 <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>
 <20170920174514.GE3835@my.box>
 <7D45202D-BF97-46C6-8138-F94FEE67077D@entropysolution.com>
 <2387331B-DB7E-4460-9667-271D99F69FFD@entropysolution.com>
 <20171003231652.GF3156@my.box>
Message-ID: <FE4354D5-6A2D-41BF-BD63-16EDD5B1B9A9@entropysolution.com>

Hi Neels,

Thank you for the immediate response.

What we did is we started from scratch again by reinstalling all the libraries and osmo elements using git.

We successfully installed all the elements without errors.

Thank you for your support.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>




On Oct 4, 2017, at 7:16 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote:

Hi again,

checking for LIBOSMOLEGACYMGCP... no
configure: error: Package requirements (libosmo-legacy-mgcp >= 0.0.1) were not met:

Maybe you have not installed osmo-mgw.git, where libosmo-legacy-mgcp comes
from?

We are aware that the current state of wiki and manuals does not reflect the
new repositories at all yet, working on it. Noting that a list of what is found
where and depends on what would be good.

~N

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/ee9d54ba/attachment.htm>

From ron.menez at entropysolution.com  Wed Oct  4 09:34:19 2017
From: ron.menez at entropysolution.com (Ron)
Date: Wed, 4 Oct 2017 09:34:19 +0000
Subject: osmo-bts-trx Aborted (core dumped) Error
Message-ID: <7D1E8750-4F12-4D50-A9C8-3B98C4CC03BB@entropysolution.com>

Hi All,

We successfully installed osmo-bsc, osmo-trx, and osmo-bts-trx in Ubuntu 16.04.

All osmo elements were successfully run except for osmo-bts-trx.

Upon running osmo-bts-trx while the osmo-trx and osmo-bsc is  running, ?Aborted (core dumped)? error is shown:

((*))
  |
 / \ OsmoBTS
<0017> control_if.c:788 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:102 telnet at 127.0.0.1 4241
<0012> input/ipaccess.c:884 enabling ipaccess BTS mode, OML connecting to 192.168.1.41:3002
<000b> trx_if.c:589 Open transceiver for phy0.0
<0012> input/ipa.c:129 connection done.
<0012> input/ipaccess.c:705 received ID get
<0001> oml.c:223 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX.
<0001> oml.c:223 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX.
Assert failed trx oml.c:156
backtrace() returned 10 addresses
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x4123f7]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x413692]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x42532d]
/usr/local/lib/libosmoabis.so.6(+0xbdc4) [0x7f3b6c921dc4]
/usr/local/lib/libosmoabis.so.6(+0x96ce) [0x7f3b6c91f6ce]
/usr/local/lib/libosmocore.so.8(osmo_select_main+0x242) [0x7f3b6d5c4862]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x423b64]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f3b6bf3e830]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x404e19]
Aborted (core dumped)

We tried to run the osmo-bts-trx without the osmo-bsc, it only shows ?Reason Abis close?:

((*))
  |
 / \ OsmoBTS
<0017> control_if.c:788 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:102 telnet at 127.0.0.1 4241
<0012> input/ipaccess.c:884 enabling ipaccess BTS mode, OML connecting to 192.168.1.41:3002
<000b> trx_if.c:589 Open transceiver for phy0.0
<000d> abis.c:135 Signalling link down
<0001> bts.c:208 Shutting down BTS 0, Reason Abis close
Shutdown timer expired

We know that the latter logs is normal since no osmo-bsc is running.

May we know what causes the core dumped? Is it a configuration issue in our side?

Attached also are the pcap and config files used and taken during the testing.

We used the latest git from "https://git.osmocom.org? for the installation.

TIA

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/830aad05/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts-trx core dumped.pcap
Type: application/octet-stream
Size: 63178 bytes
Desc: osmo-bts-trx core dumped.pcap
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/830aad05/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts.cfg
Type: application/octet-stream
Size: 624 bytes
Desc: osmo-bts.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/830aad05/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc_osmobsc.conf
Type: application/octet-stream
Size: 6371 bytes
Desc: openbsc_osmobsc.conf
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/830aad05/attachment-0002.obj>

From msuraev at sysmocom.de  Wed Oct  4 09:38:58 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 4 Oct 2017 11:38:58 +0200
Subject: osmo-bts-trx Aborted (core dumped) Error
In-Reply-To: <7D1E8750-4F12-4D50-A9C8-3B98C4CC03BB@entropysolution.com>
References: <7D1E8750-4F12-4D50-A9C8-3B98C4CC03BB@entropysolution.com>
Message-ID: <757a323f-9446-0070-bb32-e8a794c0cbd9@sysmocom.de>

Hi.

Could you please share .core file as well? Also, it might make sense to create a
ticket at https://osmocom.org/projects/osmotrx/issues to track it. It's much easier
to track all the related files etc via issue tracker rather than via ML.

On 04.10.2017 11:34, Ron wrote:
> Hi All,
>
> We successfully installed osmo-bsc, osmo-trx, and osmo-bts-trx in Ubuntu 16.04.
>
> All osmo elements were successfully run except for osmo-bts-trx.
>
> Upon running osmo-bts-trx while the osmo-trx and osmo-bsc is ?running, ?Aborted
> (core dumped)? error is shown:
>

-- 
Max Suraev <msuraev at 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 






From nhofmeyr at sysmocom.de  Wed Oct  4 11:28:34 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 13:28:34 +0200
Subject: what is bumpversion used for?
Message-ID: <20171004112834.GA8405@my.box>

Hi Max,

I asked before and now we have https://gerrit.osmocom.org/4127 so let me ask
again:

What is bumpversion used for in your 'make release' setup?
I would expect version bumping to be a human choice.
How is it intended to work?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/24c4a880/attachment.bin>

From msuraev at sysmocom.de  Wed Oct  4 11:33:51 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 4 Oct 2017 13:33:51 +0200
Subject: what is bumpversion used for?
In-Reply-To: <20171004112834.GA8405@my.box>
References: <20171004112834.GA8405@my.box>
Message-ID: <675b4cca-3777-ca24-0c56-6e5aef72137a@sysmocom.de>

It is human choice - you'll have to explicitly call "make release" to get the version
bumped.

What bumpversion does is helping to automate the boring details of it:
- determine current version (provided it matches the semver spec)
- pick next version number (according to semver spec)
- commit the changes to git
- tag the release commit

More details can be found in bumpversion manual.

On 04.10.2017 13:28, Neels Hofmeyr wrote:
> Hi Max,
>
> I asked before and now we have https://gerrit.osmocom.org/4127 so let me ask
> again:
>
> What is bumpversion used for in your 'make release' setup?
> I would expect version bumping to be a human choice.
> How is it intended to work?
>
> ~N


-- 
Max Suraev <msuraev at 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 






From nhofmeyr at sysmocom.de  Wed Oct  4 12:59:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 14:59:48 +0200
Subject: what is bumpversion used for?
In-Reply-To: <675b4cca-3777-ca24-0c56-6e5aef72137a@sysmocom.de>
References: <20171004112834.GA8405@my.box>
 <675b4cca-3777-ca24-0c56-6e5aef72137a@sysmocom.de>
Message-ID: <20171004125948.GB8405@my.box>

On Wed, Oct 04, 2017 at 01:33:51PM +0200, Max wrote:
> It is human choice - you'll have to explicitly call "make release" to get the version
> bumped.
> 
> What bumpversion does is helping to automate the boring details of it:
> - determine current version (provided it matches the semver spec)
> - pick next version number (according to semver spec)

How does it pick the next version number, i.e. how do I tell it whether to bump
major/minor/patch versions? Ah, I see in "Make a new release" wiki page:

  make REL=minor release

Personally, I find it rather trivial to pick a number, which would also allow
manual version skips that we might see necessary for hypothetical reasons. As
in

  make REL=2.0.1 release

If we did this, would we still use bumpversion for other tasks?
Semver validation could also be a simple regex.

If it's only us needing that program to make a release that's fine dependency
wise, so far I'm just probing what it is used for.

> - commit the changes to git

It's not bumpversion that does the commit though, right. Anyway:

What changes get committed during 'make release':
- does it empty the TODO-RELEASE?
- does it bump LIBVERSION API versions? (probably not, right?)
- does it edit the debian changelog?

> - tag the release commit

Ah, so the signed git tag is now done automatically?  Also I see on the wiki
page that it may be necessary to re-tag the release after review, anyway. Maybe
tagging the release should not happen automatically? I'd rather not add my
official personal signature to a tag before reviewing.  I also may need to pass
a GPG key ID to the tagging to sign with the proper key, I guess it's simpler
and less dangerous to leave it as a manual step...?


What do you think?
Thanks,

~N


P.S.: I'm still meaning to review the release hands-on and adjust the wiki
page, but I'm simply not getting all the things done that need attention at the
moment :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/d774ed8e/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Oct  4 14:31:27 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Oct 2017 16:31:27 +0200
Subject: IPA multiplex code in libosmo-abis? where to move gsup_client and
 oap_client?
Message-ID: <20171004143127.GD8405@my.box>

Comments are welcome for https://osmocom.org/issues/2534
I want to remove gsup_client code dup and need a place to put it. Can't go to
libosmocore, because it uses libosmo-abis' IPA Multiplex.

My main open question is: libosmo-abis sounds like it is specifically for the
A-bis interface.

But GSUP, which we use to talk to the OsmoHLR, is not at all related to A-bis.

Does it make sense to put it in libosmo-netif? Or move the IPA Multiplex to
libosmocore? And hence remove some duplication between libosmo-abis and
libosmo-netif?

What do you guys think is worth the trouble?
Just move gsup to libosmo-abis.git and care later?

Thanks!

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171004/2ba0908b/attachment.bin>

From msuraev at sysmocom.de  Wed Oct  4 15:20:39 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 4 Oct 2017 17:20:39 +0200
Subject: what is bumpversion used for?
In-Reply-To: <20171004125948.GB8405@my.box>
References: <20171004112834.GA8405@my.box>
 <675b4cca-3777-ca24-0c56-6e5aef72137a@sysmocom.de>
 <20171004125948.GB8405@my.box>
Message-ID: <9e7ec1e0-3c53-7602-0335-52d0c65b899f@sysmocom.de>

On 04.10.2017 14:59, Neels Hofmeyr wrote:
>
> Personally, I find it rather trivial to pick a number, which would also allow
> manual version skips that we might see necessary for hypothetical reasons.

I don't think we should optimize release automation for hypothetical reasons - rather
for most common use-case. After all, nothing stops us from doing every single step
manually and changing it as necessary.

> If we did this, would we still use bumpversion for other tasks?

We don't have to but I don't see why we should re-implement its functionality in the
script if it's available already.

> It's not bumpversion that does the commit though, right.

Wrong. It's bumpversion which creates a tag and does commit. It can be done without
it of course, I just don't see any benefit in reimplementing in script what is
available as a tool already.

> What changes get committed during 'make release':
> - does it empty the TODO-RELEASE?

Yes. The debian/changelog for libraries is generated from it.

> - does it bump LIBVERSION API versions? (probably not, right?)

Automatizing this would require way more efforts: we'll have to check the API/ABI
changes since last release. So it's not even on the TODO. Feel free to contribute
your ideas as to how this can be done though.

> - does it edit the debian changelog?

Yes, this is actually mentioned in
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release The
changelog is either based on TODO-RELEASE or based on commit log. I really think it
would be worth your time to read through the wiki page - it's not that long (and
partially is written by you anyway ;) and it'll help to clarify some of your
questions right away.

> Ah, so the signed git tag is now done automatically?

Again - see https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release

>   Also I see on the wiki page that it may be necessary to re-tag the release after review, anyway.

Also, it may be not necessary. I expect that in most of the cases there'll be no need
for that once we sort out the leftovers from previous manual release process
(non-semver versioning, missing entries in debian/changelog, missing release tags
etc). So far I've never needed manual re-tagging when making release on top of older
release made with "make release" - only to fix weird stuff when releasing on top of
manual releases from before.

>  Maybe tagging the release should not happen automatically?

Why?

>  I'd rather not add my official personal signature to a tag before reviewing. 

Again, why? Everything "make release" does is purely local to your machine. Nothing
is pushed to the network whatsoever. You can rollback/modify any changes the way you
see fit, and even after that it still will have to go through gerrit.

The "make release" is not intended as replacement for your decisions - it just
automates most common steps which would have to do manually otherwise. And it's way
too easy to forget about some of those? as you can see in many of our repos. I think
that's the main benefit actually - not so much in saving you some typing but making
all the necessary changes for release in a single step to make sure we don't
forget/omit something essential.

>  I also may need to pass
> a GPG key ID to the tagging to sign with the proper key, I guess it's simpler
> and less dangerous to leave it as a manual step...?

What kind of dangers do you see in automated tagging?

> P.S.: I'm still meaning to review the release hands-on and adjust the wiki
> page, but I'm simply not getting all the things done that need attention at the
> moment :/

Note: it's still not 100% finished - I plan to add changes for handling library and
non-library from the same repo, but haven't found the time yet.

-- 
Max Suraev <msuraev at 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 






From msuraev at sysmocom.de  Wed Oct  4 15:29:17 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 4 Oct 2017 17:29:17 +0200
Subject: RFC: CTRL interface and rate_ctr group names
In-Reply-To: <20171003004904.tiy6kwvem5akimge@nataraja>
References: <20171003004904.tiy6kwvem5akimge@nataraja>
Message-ID: <51768e42-7d8d-6931-62ca-a28c2e28088e@sysmocom.de>

It seems like there's bunch of corner cases in CTRL protocol due underspecification.
Would it make sense to formally specify it in smth like GNU bison and generate
parsers automatically instead of relying on manual parsing?

This would probably allow us to automatically generate docs for it as well.

On 03.10.2017 02:49, Harald Welte wrote:
> Opinions?
>
> Should we further restrict the CTRL interface strings (and those of
> systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
> of special characters such as ":-_@" but prevent any non-printable chars
> or special chars like "{|}()~[]\^`'?<>=;/+*&%$#!"?  I would support such
> a motion.  We could even make it more general and use that for all our
> identifier strings and have a general validation function that all code
> modules call whenever validating a string identifier used, such as e.g.
> osmo_fsm names, etc.
>

-- 
Max Suraev <msuraev at 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 






From laforge at gnumonks.org  Thu Oct  5 00:25:50 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Oct 2017 08:25:50 +0800
Subject: RFC: CTRL interface and rate_ctr group names
In-Reply-To: <51768e42-7d8d-6931-62ca-a28c2e28088e@sysmocom.de>
References: <20171003004904.tiy6kwvem5akimge@nataraja>
 <51768e42-7d8d-6931-62ca-a28c2e28088e@sysmocom.de>
Message-ID: <20171005002550.tzjuizdhftgdlk3c@nataraja>

On Wed, Oct 04, 2017 at 05:29:17PM +0200, Max wrote:
> It seems like there's bunch of corner cases in CTRL protocol due underspecification.
> Would it make sense to formally specify it in smth like GNU bison and generate
> parsers automatically instead of relying on manual parsing?

I don't think this is a useful investment of our time now.  If somebody
finds time/funding/resources for any major reimplementations in this area,
it should be spent on a unified CTRL+VTY configuration system - which for sure
will [have to have] a proper parser.

> This would probably allow us to automatically generate docs for it as well.

I don't really see how we can automatically generate documentation?  You would
still register individual control commands/nodes from application code, and not
from the generated parser in libosmocore.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Oct  5 00:46:16 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Oct 2017 08:46:16 +0800
Subject: IPA multiplex code in libosmo-abis? where to move gsup_client
 and oap_client?
In-Reply-To: <20171004143127.GD8405@my.box>
References: <20171004143127.GD8405@my.box>
Message-ID: <20171005004616.rdycbgwbibi3apyp@nataraja>

On Wed, Oct 04, 2017 at 04:31:27PM +0200, Neels Hofmeyr wrote:
> My main open question is: libosmo-abis sounds like it is specifically for the
> A-bis interface.

Correct.  And the IPA multiplex was first encountered by us on Abis, but was
later found at other places (A interface, for example) and even re-used by
us at more interfaces (GSUP).

> But GSUP, which we use to talk to the OsmoHLR, is not at all related to A-bis.

Correct.

> Does it make sense to put it in libosmo-netif? 

No.

> Or move the IPA Multiplex to libosmocore? And hence remove some
> duplication between libosmo-abis and libosmo-netif?

Actually, there is IPA multiplex related code in libosmocore,
libosmo-abis and libosmo-netif.  

* The core helpers should all be in libosmocore (I think the only
  function I would move from libosmo-abis is ipa_msg_push_header(), if
  similar doesn't alrady exist in libosmocore).

* the "stream server / client" implementation fits logically into
  libosmo-netif, where we already have a TCP and SCTP stream server,
  and where we also have the more modern "chan_abis_ipa_srv" code, both
  of which should probably be merged.

* libosmo-abis contains then only the "e1inp" integration of the IPA
  multiplex, i.e. making IPA look like an E1/T1 interface to our BSC.
  As much IPA related code should be reused here.  It uses the
  stream_server, and if that moves to libosmo-netif, we introduce
  a new dependency from libosmo-abis -> libosmo-netif.  However,
  we already have the inverse dependency in libosmo-netif/configure.ac
  where the only user seems to be two example programs that could also
  be moved.

The more interesting question is how to facilitate the related move[s]
without breaking backwards compatibility in every single program.

> Just move gsup to libosmo-abis.git and care later?

I don't like the approach of *knowingly* adding unrelated bits into
"wrong" libraries.  That's different from those cases where we have done
this at the time due to a lack of knowledge.

If the above is too complex and time-consuming (which might be the
case), then I'd rather keep two copies or even introduce a new library.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Oct  5 00:58:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Oct 2017 08:58:19 +0800
Subject: RFC: CTRL interface and rate_ctr group names
In-Reply-To: <20171003224848.GD3156@my.box>
References: <20171003004904.tiy6kwvem5akimge@nataraja>
 <20171003224848.GD3156@my.box>
Message-ID: <20171005005819.hi4mechj32xny35v@nataraja>

Hi Neels,

On Wed, Oct 04, 2017 at 12:48:48AM +0200, Neels Hofmeyr wrote:
> On Tue, Oct 03, 2017 at 08:49:04AM +0800, Harald Welte wrote:
> > * CTRL uses '.' to separate individual elements/nodes of the command
> > * a lot of rate_ctr groups we use so far use '.' in their group names
> >   (e.g. 'bssgp.bss_ctx') and counter names (e.g. 'tx.bytes')
> > * This makes the counters un-exportable via CTRL
> 
> I'm thinking, we could make the current rate_ctr_group_alloc() replace '.' with
> ':' automatically to fix all older and current builds' CTRL for rate_ctr. 

Has been implemented in https://gerrit.osmocom.org/#/c/4131

> At the same time we can deprecate rarate_ctr_group_alloc() and provide
> rate_ctr_group_alloc2(), which then aborts the program when rate_ctr names
> don't adhere to strict identifier rules. Thus we get a compile-time warning for
> applications that haven't reviewed correctness of rate_ctr naming
> ("rate_ctr_group_alloc() is deprecated...") and once an application has moved
> on we make sure no new non-compliant names are introduced.  However, newly
> introduced names will get checked only during run time.

I think this is too much effort.  We can easily grep through all our applications
and replace the names without missing something.  External (non-Osmocom) users
have never approached us with any feedback, so I doubt they even exist.

> Another addition could be a script like
> verify_value_string_arrays_are_terminated.py but for struct
> rate_ctr_group_desc arrays' identifier adherence, to verify even
> before compilation.

Also probably overkill?  I mean, an unterminated value_string_array will
end up in a bug.  But a counter name with '.' will only result in slight
increased memory use (once, at startup, when doing the . -> :
conversion).

> > Should we further restrict the CTRL interface strings (and those of
> > systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
> > of special characters such as ":-_@" but prevent any non-printable chars
> 
> For identifier validation, we should probably include that identifiers must not
> start with a number.

Why is that?

> I think we could also include ",~+^"

In the permitted characters?  I'm not sure, I think permitting too many
special characters just constrains what we can do in terms of core
syntax of interfaces like CTRL later on...

>   valid = isalpha(str[0]) && each(str[1..len] as c){ isalnum(c) || c in ":-_@,~+^" }

My current proposal is in https://gerrit.osmocom.org/#/c/4128

> Losely related is the OsmoHLR idea for CTRL interface to use names like
> 
>   SET subscriber.by-imsi.1234567898765.ps-enabled 1
> 
> where a CTRL identifier name is used for inputting an IMSI string. If we do the
> same identifier checking during incoming CTRL interface commands, we would
> forbid the IMSI name because it starts with a number.

I don't think there's something wrong with that.  Why no number at first
digit?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ron.menez at entropysolution.com  Thu Oct  5 02:30:30 2017
From: ron.menez at entropysolution.com (Ron)
Date: Thu, 5 Oct 2017 02:30:30 +0000
Subject: osmo-bts-trx Aborted (core dumped) Error
In-Reply-To: <757a323f-9446-0070-bb32-e8a794c0cbd9@sysmocom.de>
References: <7D1E8750-4F12-4D50-A9C8-3B98C4CC03BB@entropysolution.com>
 <757a323f-9446-0070-bb32-e8a794c0cbd9@sysmocom.de>
Message-ID: <948FD439-57A1-4B4D-8937-47AE9240BDBB@entropysolution.com>

Hi Max,

Thanks for the immediate reply.

Attached is the core dumped file (.crash).

We?ll also try to create a ticket to the URL provided.

If this may help, this is the logs from OSMO-BSC every time the error shows from OSMO-BTS:

Thu Oct  5 10:24:25 2017 <0023> input/ipa.c:263 accept()ed new link from 192.168.1.41 to port 3002
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix.
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.6.0.9-8a89
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported
Thu Oct  5 10:24:25 2017 <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown
Thu Oct  5 10:24:25 2017 <0023> input/ipaccess.c:241 Sign link vanished, dead socket
Thu Oct  5 10:24:25 2017 <0023> input/ipaccess.c:69 Forcing socket shutdown with no signal link set
Thu Oct  5 10:24:25 2017 <0025> bsc_init.c:377 Lost some E1 TEI link: 1 0x7f3458cad070

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>


On Oct 4, 2017, at 5:38 PM, Max <msuraev at sysmocom.de<mailto:msuraev at sysmocom.de>> wrote:

Hi.

Could you please share .core file as well? Also, it might make sense to create a
ticket at https://osmocom.org/projects/osmotrx/issues to track it. It's much easier
to track all the related files etc via issue tracker rather than via ML.

On 04.10.2017 11:34, Ron wrote:
Hi All,

We successfully installed osmo-bsc, osmo-trx, and osmo-bts-trx in Ubuntu 16.04.

All osmo elements were successfully run except for osmo-bts-trx.

Upon running osmo-bts-trx while the osmo-trx and osmo-bsc is  running, ?Aborted
(core dumped)? error is shown:


--
Max Suraev <msuraev at sysmocom.de<mailto:msuraev at 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/8dd6398f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _usr_local_osmo-bts_src_osmo-bts-trx_osmo-bts-trx.0.crash
Type: application/octet-stream
Size: 215136 bytes
Desc: _usr_local_osmo-bts_src_osmo-bts-trx_osmo-bts-trx.0.crash
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/8dd6398f/attachment.obj>

From laforge at gnumonks.org  Thu Oct  5 07:35:44 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Oct 2017 15:35:44 +0800
Subject: randomness of identifiers
In-Reply-To: <83B20A61-C1DD-4335-8C5E-3F4D8AEE017E@freyther.de>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
 <83B20A61-C1DD-4335-8C5E-3F4D8AEE017E@freyther.de>
Message-ID: <20171005073544.jysco4eyb7366vl5@nataraja>

Hi Holger,

On Thu, Sep 28, 2017 at 12:04:04PM +0800, Holger Freyther wrote:
> > On 27. Sep 2017, at 19:57, Harald Welte <laforge at gnumonks.org> wrote:
> > 
> 
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> > like rand() or any other pseudo-random generator of significantly large
> > period is sufficient *if* it is seeded by a non-predictable value.  So
> > something like seeding with getrandom() result should be fine?
> 
> GLIBC rand() maybe but "any other" not. E.g. if it is a Mersenne Twister
> than observing ~624 TMSIs could be enough to predict past and future state.

thanks for your input.

> Picking something like RAND_bytes of OpenSSL for TMSIs seems to be the
> best way. It will re-seed itself (and we are not forking). 

Ok, then let's do that.

> If the OpenSSL dependency is too bad (license compatibility, the move to the Apache license
> could help us here for GPLv3+ software) 

Yes, the new apache-style license makes this less of a headache.

So then we conclude for now:

* TMSIs and other temp identifiers: openssl RAND_bytes()
* random challenges for authentication: also RAND_bytes, or getrandom()?
* secret key generation (which we don't implement, so far: ?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Thu Oct  5 08:33:49 2017
From: holger at freyther.de (Holger Freyther)
Date: Thu, 5 Oct 2017 16:33:49 +0800
Subject: randomness of identifiers
In-Reply-To: <20171005073544.jysco4eyb7366vl5@nataraja>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
 <83B20A61-C1DD-4335-8C5E-3F4D8AEE017E@freyther.de>
 <20171005073544.jysco4eyb7366vl5@nataraja>
Message-ID: <78542B30-A0A3-4412-83BA-A2E93297A993@freyther.de>


> On 5. Oct 2017, at 15:35, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Holger,

Hi,


>> Picking something like RAND_bytes of OpenSSL for TMSIs seems to be the
>> best way. It will re-seed itself (and we are not forking). 
> 
> Ok, then let's do that.

Maybe to expand on the "forking" part. OpenSSL didn't (and might not do
it right now) re-seed on fork. This created some security issues on other
platforms (maybe the most noticeable was Android, e.g. two processes
generating the same random numbers).



>> If the OpenSSL dependency is too bad (license compatibility, the move to the Apache license
>> could help us here for GPLv3+ software) 
> 
> Yes, the new apache-style license makes this less of a headache.
> 
> So then we conclude for now:
> 
> * TMSIs and other temp identifiers: openssl RAND_bytes()
> * random challenges for authentication: also RAND_bytes, or getrandom()?
> * secret key generation (which we don't implement, so far: ?

I would use RAND_bytes() in all of these cases

From msuraev at sysmocom.de  Thu Oct  5 08:55:33 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 5 Oct 2017 10:55:33 +0200
Subject: randomness of identifiers
In-Reply-To: <20171005073544.jysco4eyb7366vl5@nataraja>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
 <83B20A61-C1DD-4335-8C5E-3F4D8AEE017E@freyther.de>
 <20171005073544.jysco4eyb7366vl5@nataraja>
Message-ID: <d8bb3027-fd01-a73c-ed2c-149a08c4a5e5@sysmocom.de>

On 05.10.2017 09:35, Harald Welte wrote:
> Yes, the new apache-style license makes this less of a headache. 

The process of relicensing is not finished yet and it's unclear when it'll be. Also,
I'm not sure when (if at all) newly licensed version will hit all the .deb
distributions which we support.

> So then we conclude for now:
>
> * TMSIs and other temp identifiers: openssl RAND_bytes()
> * random challenges for authentication: also RAND_bytes, or getrandom()?

Both RAND_bytes() and getrandom() might fail to generate random data.
Both use /dev/urandom and might deplete entropy pool.
Both are non-blocking.

RAND_bytes() creates licensing problem (which might be fixed eventually on some of
the supported distributions).

Which argument for preferring RAND_bytes() over getrandom() have I missed?

> * secret key generation (which we don't implement, so far: ?
Do we have any plans implementing it in foreseeable future?

-- 
Max Suraev <msuraev at 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 






From anindya.s at toshniwalcontrols.com  Thu Oct  5 09:28:47 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Thu, 5 Oct 2017 14:58:47 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171003230557.GE3156@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
Message-ID: <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>

Hello,

I didnot build osmo-bsc from source rather I installed from ubuntu software
centre. I believe its the old one. But can you tell me why do I dont see
nothing when I try to filter pcap trace with SCCP, M2UA etc Can you tell me
what I might be missing out here.

Thanks
Anindya

On Wed, Oct 4, 2017 at 4:35 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Tue, Oct 03, 2017 at 12:54:56PM +0530, Anindya Sankar Roy wrote:
> > Hello,
> >
> >  I need some help regarding configuration of 3rd party msc to the
> openbsc.
>
> The binary you are looking at would be osmo-bsc. During the current code
> refactoring we have two versions, one (old) osmo-bsc from openbsc.git using
> SCCPlite, and one (new) osmo-bsc from osmo-bsc.git using SCCP/M3UA.
>
> There is no proper documentation for the new SCCP/M3UA yet, but you can
> examine
> configuration in the osmo-gsm-tester "aoip_*" runs on
> https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/
> job/osmo-gsm-tester_run/
>
> The old SCCPlite osmo-bsc should be documented at
> https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Manuals
>
> Let me plug again that connecting osmo-bsc with a third-party MSC is
> likely to
> be non-trivial, and you may greatly benefit from professional support by
> one of
> the companies proficient in the Osmocom code base. Purchasing support is
> also a
> way of supporting ongoing development of the open Osmocom code base; e.g.
> the
> mail you are receiving now is made possible by my employer, sysmocom.de.
>
> ~N
>
> --
> - Neels Hofmeyr <nhofmeyr at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/d2928c6a/attachment.htm>

From ringsignature at riseup.net  Thu Oct  5 09:56:51 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 09:56:51 +0000
Subject: prng change feedback
Message-ID: <414e491e3c9c40ba8e960611691aed90@riseup.net>

Hello,

Apologies in advance for not responding to the relevant thread/message
IDs. First time poster, long time reader.

Reviewing the relevant email thread about "randomness of identifiers"
and the design in the proposed changes [0] by Max, it seems that the
patch is reasonable with one or two exceptions.

Using OpenSSL is neither necessary, nor sufficient. My understanding is
that it brings other restrictions on the use of the RNG, the state of
the process, as well as a history of serious security concerns. There
are a number of OpenSSL forks such as LibreSSL that seem to be
addressing memory safety which might be a better choice.

Many user space PRNGs now use getrandom() internally with added
complexity in user space which does not seem strictly necessary. If the
system RNG is properly seeded at boot, getrandom() should not block at
any later point in the system's lifetime. After Nadia Heninger's work[1]
attacking the Linux PRNG, the kernel team greatly improved the state of
the kernel's RNG/RNG interfaces. If the system RNG is not properly
seeded, it is game over. Systems running OpenBSC need to have
cryptographically secure source of random numbers. If a user space
cryptographic library really is required, it would probably be better to
use NaCL [2] which is a well designed library for cryptography. It
considers many cryptographic concerns such as various side channel
attacks and properly handles each concern in a systematic manner.
OpenSSL and its family do not seem to have been so carefully designed.

There was recently an interesting design posted [3] by djb about the
design of "Fast-key-erasure random-number generators" which sounds
exactly like what is desired for this use case. It should be extremely
easy to implement. Still, the use of getrandom() without re-seeding is
probably necessary and should also be sufficient even for non GNU/Linux
systems.

Returning to Max's patch:

[4] - A lack of a good random number generator should be a hard
build/runtime failure.
[5] - GNU_TLS is suggested and on the mailing list, OpenSSL, neither
seems to be needed.

Using glibc interface is less complicated than a full user space RNG.
Has anyone reviewed it? Can it fail? If so, how does it fail? It is
simple enough that intuitively it should be safe. Using the system call
directly should ensure the guarantees of the API are met without any
issues. The issue of re-seeding [6] is also one worth re-considering.

One lesson learned from various problems with TLS is worth considering
here as well: it should be secure to expose random outputs from the
(P)RNG and still, it is better to _never_ expose random outputs directly
to the network or to an attacker. A simple design for that is simply to
hash or encrypt random bytes as djb suggests in his [3] design. Raw PRNG
bytes may allow an attacker to break your PRNG as was the case with
ExtendedRandom and DualEC [7]. The Debian OpenSSL case [8] is also
informative, though of a completely different class of worst case
failures, one hopes.

Regarding the conclusion of the reviewer: merging Max's code while
removing the rand() failure mode would be a net improvement for OpenBSC.
The build should fail without getrandom(). Is there any system where
this is an expected failure mode? Anything more complex probably
deserves a design discussion with a well defined threat model for a
given system.

Happy Hacking,
RS

As an aside: If for some reason there is no cryptographically secure
hardware RNG on the OpenBSC system, one wonders if it might be of
interest to use the available RF interfaces as part of a design for such
an RNG. There would be concerns about adversarial control of inputs, of
course. It is also reasonable to try to have multiple sources of
entropy, especially if the only hardware RNG device is one that isn't
verifiable by end users such as RDRAND [9].

[0] https://gerrit.osmocom.org/#/c/1526
[1] https://crypto.stanford.edu/RealWorldCrypto/slides/nadia.pdf
[2] https://nacl.cr.yp.to/features.html
[3] https://blog.cr.yp.to/20170723-random.html
[4] https://gerrit.osmocom.org/#/c/1526/8/utils/osmo-auc-gen.c
[5] https://gerrit.osmocom.org/#/c/1526/8//COMMIT_MSG
[6] https://blog.cr.yp.to/20140205-entropy.html
[7] https://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29
[8]
https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-openssl-bug/
[9] https://en.wikipedia.org/wiki/RdRand#Reception


From nhofmeyr at sysmocom.de  Thu Oct  5 11:09:40 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 5 Oct 2017 13:09:40 +0200
Subject: prng change feedback
In-Reply-To: <414e491e3c9c40ba8e960611691aed90@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
Message-ID: <20171005110940.GA3133@my.box>

Hey RS,

thanks for your excellent input on P/RNG!

There's a lot in it, let me first off sprinkle a few remarks...

On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote:
> system RNG is properly seeded at boot, getrandom() should not block at
> any later point in the system's lifetime.

What about an attacker firing endless events that cause us to generate new
TMSIs and ends up exhausting the entropy pool? AFAIK that's a real possibility?

> As an aside: If for some reason there is no cryptographically secure
> hardware RNG on the OpenBSC system, one wonders if it might be of
> interest to use the available RF interfaces as part of a design for such
> an RNG. There would be concerns about adversarial control of inputs, of
> course.

It might well be possible to use RF noise as entropy, but the HLR that is
generating the RAND bytes is layers away from the BTS and its antenna. If all
run on the same small integrated box, somehow getting RF noise from the DSP and
feeding entropy to the system which in turn gets used on the other end by the
HLR is a possibility, but not really when the HLR is, as by the usual GSM
design, in a central location serving numerous cells.


Would be interesting to run a few tests on how quickly we can end up in entropy
exhaustion. Using getrandom() always would be the easiest and safest. Saying
that we prefer to be quick rather than secure sounds wrong indeed. But if we
practically block because of too little entropy, then we annoy lab / testing
setups that don't care about security, and we provide a DoS attack vector.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/a079a24a/attachment.bin>

From msuraev at sysmocom.de  Thu Oct  5 11:37:30 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 5 Oct 2017 13:37:30 +0200
Subject: prng change feedback
In-Reply-To: <20171005110940.GA3133@my.box>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
Message-ID: <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>

I feel an urge to re-iterate few points - see below.
N. B: I'm talking about concrete code available in gerrit.

On 05.10.2017 13:09, Neels Hofmeyr wrote:
> On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote:
>> system RNG is properly seeded at boot, getrandom() should not block at
>> any later point in the system's lifetime.
> What about an attacker firing endless events that cause us to generate new
> TMSIs and ends up exhausting the entropy pool?

It still won't block. See https://gerrit.osmocom.org/#/c/1526/

> AFAIK that's a real possibility?

Not sure either way: the attacker should deplete entropy faster than kernel gathers it.

Also, it's irrelevant for RAND_bytes() vs getrandom() discussion: both use the same
entropy pool, both will generate "not good enough" random bytes if out of entropy.

So the context for this part of the discussion is in:
https://gerrit.osmocom.org/#/c/3819/
https://gerrit.osmocom.org/#/c/3820/
https://gerrit.osmocom.org/#/c/3821/
Meaning: what do we do if we don't get "random enough" data?

So far we've just logged it and carried on with insecure rand(). Could/should we do
better? Should we fail? Should we let user decide via config option?

> Would be interesting to run a few tests on how quickly we can end up in entropy
> exhaustion.

I think it's more of an academic exercise at this point: even if our tests would show
that we can't deplete it, it doesn't mean that attacker couldn't come up with better
ways. So we should decide what should be done when this happens. So far the decision
was to "log and forget". Should we change it?

>  But if we practically block because of too little entropy

No, we don't. See https://gerrit.osmocom.org/#/c/1526/

The patch was initiated by the need to fix licensing issue, so it preserves all the
properties of original code:
- it does not block
- it uses insecure random

Since we're touching this part of the code anyway, we might also change the way we
treat entropy depletion.

But, it's somewhat orthogonal to the use of getrandom(): we can change the way we
deal with RAND_bytes() failure in another unrelated patch series.

Using getrandom() is not introducing any problems with the random data which are not
already there. It also does not fix any of them. It's good that discussion around it
attracted our attention to those problems but I think we should keep in mind that
those are related but different issues.

-- 
Max Suraev <msuraev at 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 






From ringsignature at riseup.net  Thu Oct  5 12:20:21 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 05:20:21 -0700
Subject: prng change feedback
In-Reply-To: <20171005110940.GA3133@my.box>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
Message-ID: <bc917cf211ad939860b22423ce1efeb7@riseup.net>

On 2017-10-05 11:09, Neels Hofmeyr wrote:
> Hey RS,
> 
> thanks for your excellent input on P/RNG!
> 

I'm glad it may be useful.

> There's a lot in it, let me first off sprinkle a few remarks...
> 
> On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote:
>> system RNG is properly seeded at boot, getrandom() should not block at
>> any later point in the system's lifetime.
> 
> What about an attacker firing endless events that cause us to generate new
> TMSIs and ends up exhausting the entropy pool? AFAIK that's a real possibility?
> 

Could you quantify that? What is the process by which an attacker would
be able to cause new TMSI generation? Does it require interactivity from
them or can they simply flood OpenBSC with a packet that triggers a the
creation of a TMSI? If such a flood is possible, that suggests a
security problem at the least and a possible entropy problem.

On the topic of exhausting the entropy pool: as long as a modern
GNU/Linux system is properly seeded at boot, /dev/urandom is guaranteed
to not block and to continue to emit cryptographically secure random
numbers. The entropy post by djb discusses the trade offs of seed-once
versus seed-many-times.

I think it is reasonable to seed-once at system boot and to simply
always use getrandom() with the assumption that you cannot exhaust the
entropy pool. The Linux kernel version 3.16 appears to be when the
kernel greatly improved with regard to the random interface. I think on
many modern GNU/Linux systems (2017-03-13 RANDOM(4) says so),
getrandom() will block until it is initialized:

        The  /dev/random  interface  is considered a legacy interface,
and /dev/urandom is preferred and sufficient in
       all use cases, with the exception of applications which require
randomness during early boot time;  for  these
       applications, getrandom(2) must be used instead, because it will
block until the entropy pool is initialized.

In fact, internally in the kernel, it was once and should still be the
case that the entropy pool is being constantly updated with timer and
interrupt information, in addition to other sources. In a sense, there
is no seed-once option - only a seed once with csprng source, then seed
many times with other sources including possible csprng sources. Some of
those inputs may be controlled or influenced by an attacker but such an
attack would be against the entire /dev/random interface. That is
definitely a good research project and I'm sure Professor Heninger is
already working on it. With regard to the entire PRNG being broken, this
is also why I suggested to hash or transform the output bytes, just in
case, something is broken as a defense in depth strategy. If an attacker
can break the PRNG and also predict the preimage of H(RandomBytes), then
they probably don't need the RandomBytes in the first place and the RNG
is almost certainly beyond salvation. This would have stopped the
*practical* exploitation of DualEC in TLS but it almost certainly
wouldn't stop another Debian OpenSSL fiasco.

If one is not convinced by the notion that one 128bit or 256bit seed at
boot is good for say, 2^64 outputs even with these internal reseeding
operations, and you expect to use that many outputs, reseeding could be
done with a userspace rng daemon to hardware bridge like rng-tools.

There are a few free and open hardware designs such as the Gnuk (in the
NeuG configuration) that can be re-purposed as a hardware RNG. I recall
that the device specifically uses a trick with an ADC that can fail very
badly. It seems to me that a properly designed RNG that is cheap to
build and easy to buy would be very nice as a project too.

Now down to the brass tacks:

How much random data does OpenBSC currently use in a given period of
time, say one day?
Is it really larger than the theoretical limits of the outputs for
/dev/urandom?
What are the system requirements for OpenBSC with regard to a hardware
rng or manual seeding?
Does OpenBSC only run on Linux or BSD systems with the getrandom()
interface?
Does OpenBSC store random seed data between boots?
Could someone share the value of /proc/sys/kernel/random/entropy_avail
from a typical OpenBSC machine?

>> As an aside: If for some reason there is no cryptographically secure
>> hardware RNG on the OpenBSC system, one wonders if it might be of
>> interest to use the available RF interfaces as part of a design for such
>> an RNG. There would be concerns about adversarial control of inputs, of
>> course.
> 
> It might well be possible to use RF noise as entropy, but the HLR that is
> generating the RAND bytes is layers away from the BTS and its antenna. If all
> run on the same small integrated box, somehow getting RF noise from the DSP and
> feeding entropy to the system which in turn gets used on the other end by the
> HLR is a possibility, but not really when the HLR is, as by the usual GSM
> design, in a central location serving numerous cells.

Understood.

As a slight digression: There was once some kind of Ubuntu cloud project
[1] called Pollinate to solve this for virtual machines and other
systems with no direct hardware entropy source. While that seems
excessive for this situation, it's a reasonably good overview of how
another project shares entropy over the network. Over HTTP there are raw
bytes on the network, while over HTTPS it has the problem of needing
entropy to start a secure TLS session. One option might be to ensure
that the devices are seeded at install time, another might be to extend
the already existing protocols to share entropy data from a system which
has some, and another might just be to raise the default system
requirements to include one or two RNG devices. There are many
strategies that seem promising and all of them require around 128 or 256
bits of entropy at boot time, every boot.
 
> Would be interesting to run a few tests on how quickly we can end up in entropy
> exhaustion. Using getrandom() always would be the easiest and safest. Saying
> that we prefer to be quick rather than secure sounds wrong indeed. But if we
> practically block because of too little entropy, then we annoy lab / testing
> setups that don't care about security, and we provide a DoS attack vector.

It would be surprising if one was able to exhaust it. I would expect an
RF denial of service for local clients before I would expect the Linux
/dev/urandom PRNG to output predictable sequences based on asking for
random TIMSI data.

Happy Hacking,
RS

[0] https://www.gniibe.org/memo/development/gnuk/rng/neug.html
[1]
http://people.canonical.com/~kirkland/Random%20Seeds%20in%20Ubuntu%2014.04%20LTS%20Cloud%20Instances.pdf
[2] https://launchpad.net/pollen


From ringsignature at riseup.net  Thu Oct  5 12:40:11 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 12:40:11 +0000
Subject: prng change feedback
In-Reply-To: <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
Message-ID: <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>

On 2017-10-05 11:37, Max wrote:
> I feel an urge to re-iterate few points - see below.
> N. B: I'm talking about concrete code available in gerrit.
> 
> On 05.10.2017 13:09, Neels Hofmeyr wrote:
>> On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote:
>>> system RNG is properly seeded at boot, getrandom() should not block at
>>> any later point in the system's lifetime.
>> What about an attacker firing endless events that cause us to generate new
>> TMSIs and ends up exhausting the entropy pool?
> 
> It still won't block. See https://gerrit.osmocom.org/#/c/1526/
> 

As I understand the getrandom() interface in modern Linux systems - it
is documented to block until it is initialized and then never block
again - is that an incorrect understanding of that interface?

>> AFAIK that's a real possibility?
> 
> Not sure either way: the attacker should deplete entropy faster than
> kernel gathers it.

Gathering entropy is orthogonal and also important. The core issue as I
understand it is *expanding* available entropy with a PRNG construction
from an original seed at boot time. Is an attacker really able to
deplete the PRNG's theoretical output limit? If we want to be extremely
conservative, lets say that is 2^64 outputs is the limit, would the
system really not receive another 128 bits of entropy in some manner
before that output limit is reached? Just on network card interrupts and
timers alone of fetching the TIMSI, I would expect the /dev/random
interface to be reseeding the internal prng pool. An attacker could
easily gather 128bits of TIMSI data but that expenditure does not
directly correspond to the number of input bits at seed time. That's one
nice property of the PRNG over a direct RNG interface.

> Also, it's irrelevant for RAND_bytes() vs getrandom() discussion: both
> use the same
> entropy pool, both will generate "not good enough" random bytes if out
> of entropy.

Agreed. The main reason to use getrandom() is that it is simpler and
ultimately what most projects need to use unless they directly read from
a device such as /dev/random, /dev/urandom, or another hardware device
of some kind.

> 
> So the context for this part of the discussion is in:
> https://gerrit.osmocom.org/#/c/3819/
> https://gerrit.osmocom.org/#/c/3820/
> https://gerrit.osmocom.org/#/c/3821/
> Meaning: what do we do if we don't get "random enough" data?
> 
> So far we've just logged it and carried on with insecure rand().
> Could/should we do
> better? Should we fail? Should we let user decide via config option?

Yes, I think getrandom() is a better default and in fact, the only safe
interface. I suggest failing the build absent a getrandom() system
call/glibc interface. Additionally, it would be good to ensure that any
system running OpenBSC has some source of entropy beyond interrupts and
timing - is that already the case?

> 
>> Would be interesting to run a few tests on how quickly we can end up in entropy
>> exhaustion.
> 
> I think it's more of an academic exercise at this point: even if our
> tests would show
> that we can't deplete it, it doesn't mean that attacker couldn't come
> up with better
> ways. So we should decide what should be done when this happens. So
> far the decision
> was to "log and forget". Should we change it?

It would be good to know the theoretical limits of /dev/urandom from a
given random seed absent any other influences. I was not able to find a
clear explanation and used a simple rule of thumb to come up with 2^64
(n bits / 2) outputs. It seems reasonable to log a low entropy situation
- but what exactly are the conditions for that situation?

>>  But if we practically block because of too little entropy
> 
> No, we don't. See https://gerrit.osmocom.org/#/c/1526/
> 
> The patch was initiated by the need to fix licensing issue, so it
> preserves all the
> properties of original code:
> - it does not block
> - it uses insecure random
> 

Understood.

> Since we're touching this part of the code anyway, we might also
> change the way we
> treat entropy depletion.

Is there a system wide entropy depletion monitor in place?

> But, it's somewhat orthogonal to the use of getrandom(): we can change
> the way we
> deal with RAND_bytes() failure in another unrelated patch series.
> 
> Using getrandom() is not introducing any problems with the random data
> which are not
> already there. It also does not fix any of them. It's good that
> discussion around it
> attracted our attention to those problems but I think we should keep
> in mind that
> those are related but different issues.

Using getrandom() is strictly better based on my understanding of the
interface.

Happy Hacking,
RS


From msuraev at sysmocom.de  Thu Oct  5 13:17:29 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 5 Oct 2017 15:17:29 +0200
Subject: prng change feedback
In-Reply-To: <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
 <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
Message-ID: <74ee4c4e-729c-8127-bd22-69c66ceda552@sysmocom.de>

On 05.10.2017 14:40, ringsignature at riseup.net wrote:
>
> As I understand the getrandom() interface in modern Linux systems - it
> is documented to block until it is initialized and then never block
> again - is that an incorrect understanding of that interface?

More like incomplete. We use it with *GRND_NONBLOCK parameter to make sure it never
blocks.*

>
> Additionally, it would be good to ensure that any
> system running OpenBSC has some source of entropy beyond interrupts and
> timing - is that already the case?

Out of curiosity - is there a way to check for this programmatically?

>
> Is there a system wide entropy depletion monitor in place?

Not that I know of. Is it some sort of a program or some kernel sysctl knob?

-- 

Max Suraev <msuraev at 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 






From ringsignature at riseup.net  Thu Oct  5 13:57:15 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 13:57:15 +0000
Subject: prng change feedback
In-Reply-To: <74ee4c4e-729c-8127-bd22-69c66ceda552@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
 <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
 <74ee4c4e-729c-8127-bd22-69c66ceda552@sysmocom.de>
Message-ID: <81ee236dade410d0e45ff479f809068a@riseup.net>

On 2017-10-05 13:17, Max wrote:
> On 05.10.2017 14:40, ringsignature at riseup.net wrote:
>>
>> As I understand the getrandom() interface in modern Linux systems - it
>> is documented to block until it is initialized and then never block
>> again - is that an incorrect understanding of that interface?
> 
> More like incomplete. We use it with *GRND_NONBLOCK parameter to make
> sure it never
> blocks.*

OK. If it is called at startup a single time without that parameter, all
subsequent calls should be completely non-blocking and the interface
promises to provide CSPRNG quality random bits. This is strictly an
improvement over rand() and when getrandom() isn't available on a
system, extra work will be required. Are there any such systems?

> 
>>
>> Additionally, it would be good to ensure that any
>> system running OpenBSC has some source of entropy beyond interrupts and
>> timing - is that already the case?
> 
> Out of curiosity - is there a way to check for this programmatically?

It is possible to check for the presence of some devices by checking CPU
flags (RDRAND, etc).

In theory, a call to getrandom() with no flags set should also tell you
if the system itself thinks if it has entropy. If the call doesn't
block, there is something generating data that the system considers to
be entropy.

>>
>> Is there a system wide entropy depletion monitor in place?
> 
> Not that I know of. Is it some sort of a program or some kernel sysctl knob?

There is an entry in /proc which provides an estimate:
/proc/sys/kernel/random/entropy_avail

I wrote a small benchmark in C to use getrandom() to fetch random bytes
using the SYS_getrandom system call. The entropy_avail value fluctuated
between 3820 and 3830 consistently. It doesn't seem that fetching many
hundreds of megabytes of random data impacted the system's PRNG entropy
pool estimation. This seems to be what is expected: the original entropy
is expanded by the PRNG and reading the output of the PRNG does not
exhaust the pool with a 1:1 ratio.

Happy Hacking,
RS


From nhofmeyr at sysmocom.de  Thu Oct  5 15:13:42 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 5 Oct 2017 17:13:42 +0200
Subject: build artifact store is quite large
Message-ID: <20171005151342.GA7165@ass40.sysmocom.de>

Hi blobb,

I noticed today that our Osmocombuild1's disk is full. It has 420G of
space filled up, so it's not exactly the artifact store's fault, but I
noticed that it is 3.1 G large, a tad more than I expected.

Is the below status expected?

Thanks!
~N


root at build-1 /home/osmocom-build/jenkins_build_artifact_store # du -hs *
286M  OpenBSC-gerrit_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8
52M OpenBSC-gerrit_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
286M  OpenBSC-gerrit_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8
145M  OpenBSC-gerrit_IU=--enable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
73M OpenBSC-gerrit_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
52M OpenBSC_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
805M  OpenBSC_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8
78M OpenBSC_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
701M  OpenBSC_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8
218M  OpenBSC_IU=--enable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
218M  OpenBSC_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8
218M  OpenBSC_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8
4.0K  tmp



root at build-1 /home/osmocom-build/jenkins_build_artifact_store # ls * -alh
OpenBSC-gerrit_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8:
total 286M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Oct  1 05:18 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  7 17:21 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 14:30 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 26 11:54 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 21 16:57 libosmocore.master.4306363_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 23 14:56 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 25 15:56 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 14 14:37 libosmocore.master.b2e41cc_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  1 05:18 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 11:41 libosmocore.master.b9759db_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:40 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:16 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz

OpenBSC-gerrit_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 52M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 14:30 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 14:30 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 11:41 libosmocore.master.b9759db_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz

OpenBSC-gerrit_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8:
total 286M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Oct  1 05:18 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  7 17:21 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 14:30 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 26 11:54 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 21 16:57 libosmocore.master.4306363_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 23 14:56 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 25 15:56 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 14 14:37 libosmocore.master.b2e41cc_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  1 05:18 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 11:41 libosmocore.master.b9759db_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:40 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:16 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz

OpenBSC-gerrit_IU=--enable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 145M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 14:32 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 14:32 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 11:42 libosmocore.master.b9759db_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz

OpenBSC-gerrit_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 73M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 14:32 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 14:32 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz

OpenBSC_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 52M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 23:07 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 17:50 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:07 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.9e6dfa0.tar.gz

OpenBSC_IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8:
total 805M
drwxr-xr-x  2 osmocom-build osmocom-build  12K Oct  5 03:36 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  6 12:31 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 17:50 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:26 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.2778ae2.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:07 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.9e6dfa0.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 27 12:36 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 26 10:29 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 20 01:20 libosmocore.master.4306363_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 27 13:10 libosmocore.master.463deef_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 03:45 libosmocore.master.4a31ffa_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 27 16:15 libosmocore.master.505c965_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 23 14:34 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 24 05:05 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 25 11:06 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 27 14:05 libosmocore.master.6f41767_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  7 22:59 libosmocore.master.889ab16_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 15 17:19 libosmocore.master.98f6482_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 17 17:05 libosmocore.master.98f6482_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 01:30 libosmocore.master.a52d839_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 00:36 libosmocore.master.a52d839_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 18 15:08 libosmocore.master.a52d839_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 18 20:05 libosmocore.master.a52d839_libosmo-abis.master.d329291_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 21 23:52 libosmocore.master.b022c86_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 14 04:10 libosmocore.master.b2e41cc_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  4 02:45 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 30 14:04 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  4 05:56 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.d966b0f_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  5 03:36 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.c98bf1b_libosmo-sccp.master.d966b0f_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  9 01:55 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:26 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 17:36 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 16:12 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz

OpenBSC_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 78M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 23:26 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 17:50 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:26 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.2778ae2.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:07 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.9e6dfa0.tar.gz

OpenBSC_IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8:
total 701M
drwxr-xr-x  2 osmocom-build osmocom-build  12K Oct  5 03:36 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  6 12:31 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 17:50 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0ab62fe.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:33 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.2778ae2.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep  5 23:07 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.9e6dfa0.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 27 12:36 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 26 10:35 libosmocore.master.383c563_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 20 01:24 libosmocore.master.4306363_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 03:48 libosmocore.master.4a31ffa_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 27 16:15 libosmocore.master.505c965_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 23 14:39 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 24 05:05 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 25 11:06 libosmocore.master.657c5b6_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.ba57d31_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 27 14:05 libosmocore.master.6f41767_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 17 17:05 libosmocore.master.98f6482_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 01:30 libosmocore.master.a52d839_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 19 00:36 libosmocore.master.a52d839_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 18 15:09 libosmocore.master.a52d839_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 18 20:05 libosmocore.master.a52d839_libosmo-abis.master.d329291_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.c63971f_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 21 23:56 libosmocore.master.b022c86_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.3488cf5_libsmpp34.master.6619771_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 14 04:11 libosmocore.master.b2e41cc_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  4 02:45 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Sep 30 14:09 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.54fa75b_libsmpp34.master.6619771_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  4 05:56 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.5994198_libosmo-sccp.master.d966b0f_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  27M Oct  5 03:36 libosmocore.master.b697df0_libosmo-abis.master.01543a1_libosmo-netif.master.c98bf1b_libosmo-sccp.master.d966b0f_libsmpp34.master.4a82bb9_openggsn.master.6045efb.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 20:26 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.14af167_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 17:36 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.3488cf5_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  26M Sep 11 16:12 libosmocore.master.d64b6ae_libosmo-abis.master.d329291_libosmo-netif.master.9c5f01e_libosmo-sccp.master.769e935_libsmpp34.master.823e711_openggsn.master.0162898.tar.gz

OpenBSC_IU=--enable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 218M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 23:28 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 17:52 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:28 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.2778ae2_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:09 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.9e6dfa0_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz

OpenBSC_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8:
total 218M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 23:35 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 17:52 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:35 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.2778ae2_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:09 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.9e6dfa0_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz

OpenBSC_IU=--enable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--enable-smpp,label=linux_amd64_debian8:
total 218M
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Sep  5 23:35 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 17:52 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.0ab62fe_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:35 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.2778ae2_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz
-rw-r--r--  1 osmocom-build osmocom-build  73M Sep  5 23:09 libosmocore.master.03516d6_libosmo-abis.master.d329291_libosmo-netif.master.03b84ec_libosmo-sccp.old_sua_libsmpp34.master.823e711_openggsn.master.9e6dfa0_libasn1c.master.aaae8c7_osmo-iuh.old_sua.tar.gz

tmp:
total 8.0K
drwxr-xr-x  2 osmocom-build osmocom-build 4.0K Oct  5 03:38 .
drwxr-xr-x 15 osmocom-build osmocom-build 4.0K Sep  5 17:52 ..


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/e7b85772/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Oct  5 17:25:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 5 Oct 2017 19:25:48 +0200
Subject: disk fill-up of Osmocombuild1, reasons
Message-ID: <20171005172548.GB7165@ass40.sysmocom.de>

I looked at why the 420G of the Osmocombuild1 root fs are full.

1)

Slave "build1-debian9-lxc" is running as lxc called 'docker'.
/var/lib/lxc/docker/rootfs/var/lib/docker/vfs/dir contains 221G in 333 docker
snapshots. It seems to me that these are growing indefinitely, that nothing is
removing docker hashes that have been built. Does anyone have a discarding
strategy ready that we can deploy there? We need to add one to avoid the build
slave filling up again. https://osmocom.org/issues/2539

For now I did
  docker rmi $(docker images -q -f dangling=true)
and rm'd a few stopped containers that had started an openbsc test:
  docker rm $(docker ps -aq)
which removed hundreds of hashes and freed ~110G
But half of the 221G are still there, not sure if we need those.

I also note that this lxc is not starting automatically after I rebooted
Osmocombuild1 (to get rid of some stuck processes).
I added
  lxc.start.auto = 1
to /var/lib/lxc/docker/config

Now the server is back up and running, the lxc is started, but the jenkins
slave refuses to connect. It tries port 45 but nothing is listening
there. I think I've hit this before but can't remember how to solve it :/
https://osmocom.org/issues/2540


2)

Slave "Osmocombuild1" is running as user osmocom-build on the host's OS itself.
The workspaces make up one large chunk of the disk fill: 94G.

Looking at OpenBSC at 3, it builds up to 3.8G from the various build matrix
workspaces, where each has a compiled libosmocore at >110MB and osmo-iuh
at >130MB. Then the parrallel builds each make an own workspace, exploding the
total. The good news is that it should cap *somewhere* and not grow
indefinitely.

We probably should adjust the OpenBSC and various gerrit jobs to clean up the
workspace after they are done. We so far never needed the binaries.
https://osmocom.org/issues/2538


~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/b7d8c115/attachment.bin>

From ringsignature at riseup.net  Thu Oct  5 22:51:47 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 15:51:47 -0700
Subject: prng change feedback
In-Reply-To: <20171005110940.GA3133@my.box>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
Message-ID: <bf376d4ce985e95c43ab91cf64e27541@riseup.net>

Hello,

> Would be interesting to run a few tests on how quickly we can end up in entropy
> exhaustion. Using getrandom() always would be the easiest and safest. Saying
> that we prefer to be quick rather than secure sounds wrong indeed. But if we
> practically block because of too little entropy, then we annoy lab / testing
> setups that don't care about security, and we provide a DoS attack vector.
>

I conducted some simple experiments with small C program running on a
quad core Intel(R) Core(TM) i5-2520M CPU. The program is in the body of
this email. It utilized only a single core at full capacity. The test
runs syscall(SYS_getrandom, &buf, bufsize, flags) in a while(1) loop.
The bufsize is 512 (bytes) for each call to SYS_getrandom. The program
measures the system entropy as SYS_getrandom is repeatedly called. As
the program uses syscall() without #defines for getrandom(), I #defined
the flags manually. The name GRND_BLOCKONCE seemed appropriate though
non-standard it meaningfully describes the defined behavior. The two
flags I tested were:

  #define GRND_BLOCKONCE 0
  #define GRND_RANDOM 0x0002

The first method of calling ensured that the syscall may block until the
system entropy pool is initialized. It did not block on my machine as
the entropy pool was initialized around two weeks ago at the last system
boot. During a ~fifteen minute run with 412100000 iterations fetching
512 bytes per iteration, the entropy pool increased from ~3700 to ~3867.
In another run over ~eleven minutes with 277200000 iterations, I found
that the pool went from ~3920 to ~3727. During the second run, I suspect
other software on my machine used the /dev/random device directly. In
both cases, the output matches my expectation of a very large ratio for
the estimated entropy bits to PRNG output bits. The core of the
iteration was effectively this single line:

  actual_bytes_fetched = syscall(SYS_getrandom, &buf, bufsize,
GRND_BLOCKONCE)

The value of actual_bytes_fetched was always equal to the size of
bufsize. It never underflowed. With GRND_BLOCKONCE, any concerns about
intermittent blocking or a denial of service vectors through getrandom()
should be be mitigated. GRND_BLOCKONCE seems ideal for TMSI generation
even if an adversary were requesting (tens of) thousands of TMSIs a
second.

The second method of calling getrandom() was configured to use the
actual bits of the random device pool as clarified in the documentation
for getrandom():

       GRND_RANDOM
              If  this  bit  is set, then random bytes are drawn from
the random source (i.e., the same source as the
              /dev/random device) instead of the urandom source.  The
random source is limited based on  the  entropy
              that  can  be obtained from environmental noise.  If the
number of available bytes in the random source
              is less than requested in buflen, the call returns just
the available random bytes.  If no random bytes
              are available, the behavior depends on the presence of
GRND_NONBLOCK in the flags argument.

The core of the iteration was the same with only a different flag set:

  actual_bytes_fetched = syscall(SYS_getrandom, &buf, bufsize,
GRND_RANDOM)

The value of actual_bytes_fetched varied at every iteration and did
often underflow. The ratio of entropy pool bits to output bits appears
to be closer to one to one. It does not seem ideal to use GRND_RANDOM
for TMSI generation, especially if a possible adversary is the
requesting party - they would seem to be able to drain the device
entropy pool very quickly. If this mode was used and it is configured to
be non-blocking, it seems that it could fail very badly.

After running the above tests and reading the related documentation, my
conclusion is that it would be reasonable to use syscall(SYS_getrandom,
&buf, bufsize, 0) as a suitable replacement for rand() in all cases
without any concrete security or performance concerns. The overhead is
also significantly less than importing or otherwise depending on
OpenSSL, GnuTLS,  NaCL, or probably even glibc. It may make sense to use
the platform's libc interface if it is available. It may also be
worthwhile to try to ensure that buffer is indeed changed. The small
program below could also easily be modified to test that the buffer is
indeed completely filled with some new data and to additionally hash the
buffer before use in any cryptographic application.

Happy Hacking,
RS

/*
 *
 * This program is Free Software under the GPLv3.
 * Copyleft ringsignature 2017.
 *
 * Compile with:
 * gcc -Wall -std=c11 -o getrandom-exhaust getrandom-exhaust.c
 *
 * */

#define _GNU_SOURCE 1
#include <sys/types.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

#define GRND_BLOCKONCE 0x0000
#define GRND_NONBLOCK 0x0001
#define GRND_RANDOM 0x0002

void pp(unsigned char *buf, uint s){
    uint z = 0;
    for (z=0; z<s; z++){
      printf("%x", buf[z]);
    }
    printf("\n");
}

void ms(unsigned char *buf, uint s, unsigned char f){
    memset(buf, f, s);
}

uint ea(void){
   FILE *f;
   uint i = 0;
   int val = 0;
   f = fopen("/proc/sys/kernel/random/entropy_avail", "r");
   if (f == NULL) { return -1; }
   i = fscanf(f, "%u", &val);  
   if (i == EOF) { return -1; }
   fclose(f);
   return val;
}

void ppea(void) {
   uint e = -1;
   e = ea();
   if (e != -1) {
       printf("Current entropy available: %u\n", e);
   } else {
       fprintf(stderr, "Error fetching currently available entropy!\n");
   }
}

void pps(uint b, uint c) {
    printf("\e[1;1H\e[2J");
    printf("getrandom status - byte size requested: %i iteration: %i\n",
b, c);
    ppea();
}

int main(void) {
    uint bufsize = 512;
    unsigned char buf[bufsize];
    int actual_bytes = 0;
    int count = 0;
    int es = ea();
    ms(buf, bufsize, 0x0);
    pps(actual_bytes, count);
    while (count != -1) {
        ms(buf, bufsize, 0x42);
        actual_bytes = syscall(SYS_getrandom, &buf, bufsize,
GRND_BLOCKONCE);
        if (actual_bytes != bufsize) {
            pps(actual_bytes, count);
            printf("getrandom underflow!\n");
            pp(buf, bufsize);
        }
        count++;
        if ( (count % 100000) == 0) { 
            pps(actual_bytes, count);
            ms(buf, bufsize, 0x47);
        }
    }
    pps(actual_bytes, count);
    printf("Original entropy estimate: %i\n", es);
    return 0;
}


From laforge at gnumonks.org  Fri Oct  6 01:03:23 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Oct 2017 09:03:23 +0800
Subject: prng change feedback
In-Reply-To: <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
 <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
Message-ID: <20171006010323.zqxrck4ncoy6q4qx@nataraja>

Hi RS,

On Thu, Oct 05, 2017 at 12:40:11PM +0000, ringsignature at riseup.net wrote:

> Yes, I think getrandom() is a better default and in fact, the only safe
> interface. I suggest failing the build absent a getrandom() system
> call/glibc interface. Additionally, it would be good to ensure that any
> system running OpenBSC has some source of entropy beyond interrupts and
> timing - is that already the case?

We of course have no idea on what systems people are using the related
osmocom components on (such as OsmoNITB, OsmoMSC, OsmoSGSN).  For some
of the smaller / deeper embedded devices (like e.g. the sysmoBTS 1002)
for sure there is no hardware random number generator and interrupts are
the only source of randomness.

However, in most realistic scenarios you would have more than one BTS
and run the NITB/MSC/SGSN on some kind of (embedded?) x86 or ARM board,
and most systems have had hardware random number generators for quite a
long time.  Yes, the question is whether you trust those, but that's
completely off-topic here in this thread.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Oct  6 01:11:53 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Oct 2017 09:11:53 +0800
Subject: prng change feedback
In-Reply-To: <bc917cf211ad939860b22423ce1efeb7@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <bc917cf211ad939860b22423ce1efeb7@riseup.net>
Message-ID: <20171006011153.jta6hnwl76ciqowi@nataraja>

Hi RS,

On Thu, Oct 05, 2017 at 05:20:21AM -0700, ringsignature at riseup.net wrote:
> On 2017-10-05 11:09, Neels Hofmeyr wrote:
> > What about an attacker firing endless events that cause us to generate new
> > TMSIs and ends up exhausting the entropy pool? AFAIK that's a real possibility?
> 
> Could you quantify that? What is the process by which an attacker would
> be able to cause new TMSI generation? Does it require interactivity from
> them or can they simply flood OpenBSC with a packet that triggers a the
> creation of a TMSI? If such a flood is possible, that suggests a
> security problem at the least and a possible entropy problem.

Well, it probably depends on the interface the attacker has access to
(Radio/Backhaul/...) and hence the threat model.

A TMSI is allocated at many possible transactions, but all of them
[should, in a sane implementation!] require authentication first, so it
requires interactivity and is not just a simple flood.

> How much random data does OpenBSC currently use in a given period of
> time, say one day?

I think for all practical installations outside of an attack scenario
that we know of, it's very little.

> What are the system requirements for OpenBSC with regard to a hardware
> rng or manual seeding?

We don't publish hardware requirements.

> Does OpenBSC only run on Linux or BSD systems with the getrandom()
> interface?

We don't officially support or build test on anything but Ubuntu >=
16.04, Debian >= 8 and FreeBSD >= 10.3.  We of course don't know what
people decide to run the code on, in the end.

> Does OpenBSC store random seed data between boots?

Not our code.  That's a task of the OS, no?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Oct  6 01:23:21 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Oct 2017 09:23:21 +0800
Subject: prng change feedback
In-Reply-To: <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
Message-ID: <20171006012321.nkomixxbodh4xha2@nataraja>

Hi RS,

> After running the above tests and reading the related documentation, my
> conclusion is that it would be reasonable to use syscall(SYS_getrandom,
> &buf, bufsize, 0) as a suitable replacement for rand() in all cases
> without any concrete security or performance concerns. The overhead is
> also significantly less than importing or otherwise depending on
> OpenSSL, GnuTLS,  NaCL, or probably even glibc. 

Thanks again for your investigation.

So the conclusion is probably, for now:
* use getrandom() with zero flags for TMSIs and other random identifiers
* use getrandom() with zero flags for RAND challenges
* use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation

> It may make sense to use the platform's libc interface if it is available. 

I would go for that, and I believe the current patch under discussion is doing
exactly that: use getrandom() if available, and fall back to the raw syscall,
if not.

Further falling back on rand() is probably a bad idea, we could simply
make this a fatal runtime error ending the program and see if anyone
ever reports that error to the mailing list.  If at all, the fall-back
should not happen automatically, but should be explicitly requested at
compile-time ("--enable-unsafe-rand"), or depend on an environment
variable, or the like.  Basically to make sure the default configuration
will be safe, and any unsafe operation requires explicit user
intervention.

> It may also be worthwhile to try to ensure that buffer is indeed
> changed. 

good point, I like that.

> The small program below could also easily be modified to test that the
> buffer is indeed completely filled with some new data and to
> additionally hash the buffer before use in any cryptographic
> application.

Yes, we could improve on that by using some hashing function on the
result, rather than using the (cs)prng output directly.  But let's keep
that as a possible future improvement for now.  Out of curiosity: What
would you recommend?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Oct  6 01:46:48 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Oct 2017 09:46:48 +0800
Subject: disk fill-up of Osmocombuild1, reasons
In-Reply-To: <20171005172548.GB7165@ass40.sysmocom.de>
References: <20171005172548.GB7165@ass40.sysmocom.de>
Message-ID: <20171006014648.nh6movjgxfrgsdbr@nataraja>

Hi Neels,

On Thu, Oct 05, 2017 at 07:25:48PM +0200, Neels Hofmeyr wrote:
> Slave "build1-debian9-lxc" is running as lxc called 'docker'.
> /var/lib/lxc/docker/rootfs/var/lib/docker/vfs/dir contains 221G in 333 docker
> snapshots. It seems to me that these are growing indefinitely, that nothing is
> removing docker hashes that have been built. Does anyone have a discarding
> strategy ready that we can deploy there? We need to add one to avoid the build
> slave filling up again. https://osmocom.org/issues/2539

I updated the ticket.  Real fix is still pending.

> I also note that this lxc is not starting automatically after I rebooted
> Osmocombuild1 (to get rid of some stuck processes).
> I added
>   lxc.start.auto = 1
> to /var/lib/lxc/docker/config
> 
> Now the server is back up and running, the lxc is started, but the jenkins
> slave refuses to connect. It tries port 45 but nothing is listening
> there. I think I've hit this before but can't remember how to solve it :/
> https://osmocom.org/issues/2540

I updated that issue, and hopefully fixed it.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ringsignature at riseup.net  Fri Oct  6 06:16:45 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Thu, 05 Oct 2017 23:16:45 -0700
Subject: prng change feedback
In-Reply-To: <20171006010323.zqxrck4ncoy6q4qx@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
 <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
 <20171006010323.zqxrck4ncoy6q4qx@nataraja>
Message-ID: <7be3802a05abd0a70b39fef23a6d74e8@riseup.net>

Hello,

On 2017-10-06 01:03, Harald Welte wrote:
> Hi RS,
> 
> On Thu, Oct 05, 2017 at 12:40:11PM +0000, ringsignature at riseup.net wrote:
> 
>> Yes, I think getrandom() is a better default and in fact, the only safe
>> interface. I suggest failing the build absent a getrandom() system
>> call/glibc interface. Additionally, it would be good to ensure that any
>> system running OpenBSC has some source of entropy beyond interrupts and
>> timing - is that already the case?
> 
> We of course have no idea on what systems people are using the related
> osmocom components on (such as OsmoNITB, OsmoMSC, OsmoSGSN).  For some
> of the smaller / deeper embedded devices (like e.g. the sysmoBTS 1002)
> for sure there is no hardware random number generator and interrupts are
> the only source of randomness.
>

Might those devices be interesting as a research target for generating
entropy from a radio interface? The specification suggests that the
device does indeed have a radio interface. If so, perhaps it would be a
useful experiment for someone to attempt to create an OsmoEntropy
subproject? I would be interested in undertaking such a project, if it
would be useful and especially if it would be used.

> However, in most realistic scenarios you would have more than one BTS
> and run the NITB/MSC/SGSN on some kind of (embedded?) x86 or ARM board,
> and most systems have had hardware random number generators for quite a
> long time.  Yes, the question is whether you trust those, but that's
> completely off-topic here in this thread.

Understood.

Happy Hacking,
RS


From ringsignature at riseup.net  Fri Oct  6 07:13:07 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Fri, 06 Oct 2017 00:13:07 -0700
Subject: prng change feedback
In-Reply-To: <20171006011153.jta6hnwl76ciqowi@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bc917cf211ad939860b22423ce1efeb7@riseup.net>
 <20171006011153.jta6hnwl76ciqowi@nataraja>
Message-ID: <93ed78f1dd636466e4dba13c9de8e942@riseup.net>

Hello,

On 2017-10-06 01:11, Harald Welte wrote:
> Hi RS,
> 
> On Thu, Oct 05, 2017 at 05:20:21AM -0700, ringsignature at riseup.net wrote:
>> On 2017-10-05 11:09, Neels Hofmeyr wrote:
>> > What about an attacker firing endless events that cause us to generate new
>> > TMSIs and ends up exhausting the entropy pool? AFAIK that's a real possibility?
>>
>> Could you quantify that? What is the process by which an attacker would
>> be able to cause new TMSI generation? Does it require interactivity from
>> them or can they simply flood OpenBSC with a packet that triggers a the
>> creation of a TMSI? If such a flood is possible, that suggests a
>> security problem at the least and a possible entropy problem.
> 
> Well, it probably depends on the interface the attacker has access to
> (Radio/Backhaul/...) and hence the threat model.
> 
> A TMSI is allocated at many possible transactions, but all of them
> [should, in a sane implementation!] require authentication first, so it
> requires interactivity and is not just a simple flood.
> 

That is reasonable. I wonder how much entropy that entire process start
to finish will use in any given authentication process? That's I
suppose, a GSM (and other related protocols) research question rather
than an OpenBSC specific question.

>> How much random data does OpenBSC currently use in a given period of
>> time, say one day?
> 
> I think for all practical installations outside of an attack scenario
> that we know of, it's very little.

That is what I'd expect - I'd also expect in the cases where it is used,
it is probably a contributory process with inputs from all communicating
peers.

> 
>> What are the system requirements for OpenBSC with regard to a hardware
>> rng or manual seeding?
> 
> We don't publish hardware requirements.

If I may humbly suggest, it may be worth suggesting that users ensure
that it is their responsibility to have a good RNG source for the Linux
kernel. There are probably a few situations where entropy failure is
catastrophic. The generation of K_i seems to be an obvious failure,
though there are probably other interesting failures where a badly
behaving handset might be able to force the the network side to compute
over a value that is unsafe in some manner. Again, some research which
is out of scope but hopefully helpful to someone reading along...

> 
>> Does OpenBSC only run on Linux or BSD systems with the getrandom()
>> interface?
> 
> We don't officially support or build test on anything but Ubuntu >=
> 16.04, Debian >= 8 and FreeBSD >= 10.3.  We of course don't know what
> people decide to run the code on, in the end.

There is a python issue [0] which explains in detail many choices that
the python project has made and why with regard to supporting os.random.
There is also an excellent "Entropy-supplying system calls" overview
page on Wikipedia [1] that is worth reviewing.

On my Debian stable machine, my glibc does not appear to have
getrandom() while my kernel does have the syscall for getrandom(). On
FreeBSD to test if the machine is properly seeded one may check the
kern.random.sys.seeded sysctl and then subsequent calls to [2]
read_random() or read_random_uio() [3] may be functionally similar.
FreeBSD appears to define those functions such that if there isn't a
DEV_RANDOM, the functions simply return 0. It appears OpenBSD supplies a
getentropy() function on their system.

getentropy() is documented on Debian as a wrapper around getrandom():
 
  DESCRIPTION
       The  getentropy() function writes length bytes of high-quality
random data to the buffer starting at the loca?
       tion pointed to by buffer.  The maximum permitted value for the
length argument is 256.

       A successful call to getentropy() always returns the requested
number of bytes of entropy.

It may make sense as a matter of portability to first look for the
syscall for getrandom(), getrandom(), getentropy(), and finally a
compile failure, in that order? I'm not sure, though whatever is
selected should be logged.

> 
>> Does OpenBSC store random seed data between boots?
> 
> Not our code.  That's a task of the OS, no?

I know that modern systems are supposed to handle this functionality. It
should be a task taken care of by the OS, of course. I believe both
officially supported platforms do handle this exact issue which is
reasonable.

Happy Hacking,
RS

[0] https://bugs.python.org/issue27266
[1] https://en.wikipedia.org/wiki/Entropy-supplying_system_calls
[2] https://svnweb.freebsd.org/base?view=revision&revision=286839
[3]
https://svnweb.freebsd.org/base/head/sys/sys/random.h?view=markup&pathrev=286839


From ringsignature at riseup.net  Fri Oct  6 08:19:17 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Fri, 06 Oct 2017 08:19:17 +0000
Subject: prng change feedback
In-Reply-To: <20171006012321.nkomixxbodh4xha2@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
Message-ID: <5aab0a3077fcc5d39dccf8112a34c456@riseup.net>

On 2017-10-06 01:23, Harald Welte wrote:
> Hi RS,
> 
>> After running the above tests and reading the related documentation, my
>> conclusion is that it would be reasonable to use syscall(SYS_getrandom,
>> &buf, bufsize, 0) as a suitable replacement for rand() in all cases
>> without any concrete security or performance concerns. The overhead is
>> also significantly less than importing or otherwise depending on
>> OpenSSL, GnuTLS,  NaCL, or probably even glibc.
> 
> Thanks again for your investigation.

You're welcome. Thanks for writing Free Software! I really appreciate
that your project is open to feedback from complete strangers!

My program is not optimized in any sense and I re-ran my program for 0
to -1 iterations with the following outcome:

 time ./getrandom-exhaust
 getrandom status - byte size requested: 512 iteration: -1
 Current entropy available: 2575
 Original entropy estimate: 3338
 
 real	170m44.814s
 user	3m50.836s
 sys	166m52.948s

I think it would be interesting to run this on any supported system and
see if the output is similar. All of the conclusions that I've reached
are based on the notion that any decreases to the entropy pool are
negligible. Furthermore that the entropy pool might increase during the
attempted exhaustion process which is probably an unrelated systems side
effect. In either case, it will never underflow and it will always
return the requested number of bytes.

> So the conclusion is probably, for now:
> * use getrandom() with zero flags for TMSIs and other random identifiers
> * use getrandom() with zero flags for RAND challenges
> * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
> 

I don't entirely disagree, however the third option creates a more
complex case that I'm not sure is worth the trouble. I would very
strongly resist the urge to believe that the raw device bits are
_better_ than the output of the PRNG. The GRND_RANDOM flag will result
in underflows of the entire systems entropy pool, which especially on an
embedded system is a halt-and-catch-fire situation. The complexity
around that failure mode might cause failures that are otherwise avoided
entirely.

>> It may make sense to use the platform's libc interface if it is available.
> 
> I would go for that, and I believe the current patch under discussion is doing
> exactly that: use getrandom() if available, and fall back to the raw syscall,
> if not.
> 

I'd suggest someone examine the failure modes for glibc before making
this decision. I expect it to be a completely sane interface which fails
nicely - though, if it doesn't, we need to consider how it fails.
Apparently it was a "long road" [0] [1] to supporting getrandom() in
glibc. The 2.25 appears to be the first release to support getrandom().
Probably the most interesting thing of note for that version is "* The
getentropy and getrandom functions, and the <sys/random.h> header file
have been added." This almost suggests to me that getentropy() and a
maximum buffer of 256 bytes is a reasonable interface to settle on.

As further reading - the people implementing Rust's random [3] have the
following view of the matter:

    Unix-like systems (Linux, Android, Mac OSX): read directly from
/dev/urandom, or from getrandom(2) system call if available.
    OpenBSD: calls getentropy(2)
    FreeBSD: uses the kern.arandom sysctl(2) mib
    Windows: calls RtlGenRandom, exported from advapi32.dll as
SystemFunction036.
    iOS: calls SecRandomCopyBytes as /dev/(u)random is sandboxed.
    PNaCl: calls into the nacl-irt-random-0.1 IRT interface.

> Further falling back on rand() is probably a bad idea, we could simply
> make this a fatal runtime error ending the program and see if anyone
> ever reports that error to the mailing list.  If at all, the fall-back
> should not happen automatically, but should be explicitly requested at
> compile-time ("--enable-unsafe-rand"), or depend on an environment
> variable, or the like.  Basically to make sure the default configuration
> will be safe, and any unsafe operation requires explicit user
> intervention.
> 
>> It may also be worthwhile to try to ensure that buffer is indeed
>> changed.
> 
> good point, I like that.

I'm not entirely sure of the best method for checking but I would expect
something like this to at least fail safely in the event of a kernel
failure:

 - allocate a fixed size buffer of 256 bytes which seems to be the most
portable size among all the OS provided interfaces
 - memset the buffer with a known value such as #define
THEMEASUREOFABYTE 0x47
 - memcmp each byte of the buffer with THEMEASUREOFABYTE to ensure that
each byte compared is the same
 - request that the OS or glibc or libc fills that same buffer with
random bytes for the size of the buffer
 - ensure that the number of bytes written is equal to the requested
size
 - memcmp each byte of the buffer with THEMEASUREOFABYTE to ensure that
each byte compared is *not* the same
 - if anything has gone wrong, return -1 and 0 (is this correct?)
 - in one possible future, hash the buffer in place to conceal the raw
outputs from the PRNG
 - return the number of bytes written to the buffer, return the buffer
full of random bytes
 
That may make a better unit test than an actual wrapper function. It
seems that for portability, it's worth considering such a wrapper as it
doesn't appear that every API has the same failure mode. There is of
course the unfortunate side effect of removing all 0x47s from your
buffer with such an approach, which leads to a suggestion of generating
a single random byte, which well, it's ??? all the way down... :-)

Such an implementation should be constant time and take into
consideration other things that might leak the random data. I'm not sure
if memcmp is ideal for that reason. I'll do some additional
research/experimentation and share the results.

>> The small program below could also easily be modified to test that the
>> buffer is indeed completely filled with some new data and to
>> additionally hash the buffer before use in any cryptographic
>> application.
> 
> Yes, we could improve on that by using some hashing function on the
> result, rather than using the (cs)prng output directly.  But let's keep
> that as a possible future improvement for now.  Out of curiosity: What
> would you recommend?

For a 512 *bit* buffer, I think hashing with SHA512 would be a fine
transformation. If the attacker can guess the input for an output of
SHA512, there is a serious problem. In which case, the hashing might
mitigate practical, casual exploitation of the problem. It might not, of
course.

For buffers that are 256 or 512 bytes, I think it could be hashed in two
or four chunks but someone smarter than me should think about that
strategy before drawing a final conclusion. There are strategies using
block ciphers rather than hashing functions that might make sense for
larger buffers. Such a block cipher would essentially become a user
space RNG of a similar design to the one from djb that I shared in
earlier in the thread. Once we're in block cipher territory, we're using
additional memory, we increase complexity, we may also have concerns
about internal key schedules, side channels, and so on. I suppose this
is another open research question for me. I'm sure someone else knows an
answer off hand but I'm not confident that I know how to do it
correctly.

Happy Hacking,
RS

[0] https://lwn.net/Articles/711013/
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17252
[2] https://doc.rust-lang.org/rand/rand/os/struct.OsRng.html


From msuraev at sysmocom.de  Fri Oct  6 12:50:05 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 6 Oct 2017 14:50:05 +0200
Subject: prng change feedback
In-Reply-To: <20171006012321.nkomixxbodh4xha2@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
Message-ID: <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>

On 06.10.2017 03:23, Harald Welte wrote:
> So the conclusion is probably, for now:
> * use getrandom() with zero flags for TMSIs and other random identifiers
> * use getrandom() with zero flags for RAND challenges

I don't think it's a good idea. It's fine for exploratory programming while
experimenting but in the library which is meant for production use behavior should be
as predictable as possible.

Using "zero flags" means that the function might or might not block which pretty-much
guarantees headaches later on when troubleshooting the code which will use it.

I think we should always opt for "least surprise" path and use GRND_NONBLOCK (as in
current patch). That way we'll never block and let the caller handle errors (if any).

> * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation

I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
/dev/random and /dev/urandom are going through the same CSPRNG so I'm not sure we
gain anything by requiring random instead of urandom.

Also, are we talking about utils/osmo-auc-gen or smth else?

> I would go for that, and I believe the current patch under discussion is doing
> exactly that: use getrandom() if available, and fall back to the raw syscall,
> if not.

Yepp, that's how it's done.

> Further falling back on rand() is probably a bad idea

Removed: it was there only because that's how OpenBSC and other apps have always used
it. But if we do not plan to use insecure random anymore than it's not needed.

-- 

Max Suraev <msuraev at 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 






From nhofmeyr at sysmocom.de  Fri Oct  6 14:19:47 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 6 Oct 2017 16:19:47 +0200
Subject: RFC: CTRL interface and rate_ctr group names
In-Reply-To: <20171005005819.hi4mechj32xny35v@nataraja>
References: <20171003004904.tiy6kwvem5akimge@nataraja>
 <20171003224848.GD3156@my.box>
 <20171005005819.hi4mechj32xny35v@nataraja>
Message-ID: <20171006141947.GA29730@my.box>

On Thu, Oct 05, 2017 at 08:58:19AM +0800, Harald Welte wrote:
> Why no number at first digit?

Hmm, no real reason now that I think of it. In programming languages the
requirement exists to easily distinguish identifiers from numeric constants. I
was going with what I know from elsewhere...

But indeed in the CTRL there are no numeric constants to distinguish from.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171006/c1501f6b/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Oct  6 14:22:40 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 6 Oct 2017 16:22:40 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
Message-ID: <20171006142240.GB29730@my.box>

On Thu, Oct 05, 2017 at 02:58:47PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
> I didnot build osmo-bsc from source rather I installed from ubuntu software
> centre. I believe its the old one. But can you tell me why do I dont see
> nothing when I try to filter pcap trace with SCCP, M2UA etc Can you tell me
> what I might be missing out here.

Unless you are using osmo-bsc packages from
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
you are most definitely using SCCPlite, i.e. no M3UA and no SCTP.

See
https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds

We are still lacking in-depth (or any) documentation on the difference between
SCCPlite and SCCP/M3UA.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171006/086b92c8/attachment.bin>

From ringsignature at riseup.net  Fri Oct  6 15:43:22 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Fri, 06 Oct 2017 08:43:22 -0700
Subject: prng change feedback
In-Reply-To: <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
Message-ID: <3c4721d4cc628948ae898a1d4222387c@riseup.net>

On 2017-10-06 12:50, Max wrote:
> On 06.10.2017 03:23, Harald Welte wrote:
>> So the conclusion is probably, for now:
>> * use getrandom() with zero flags for TMSIs and other random identifiers
>> * use getrandom() with zero flags for RAND challenges
> 
> I don't think it's a good idea. It's fine for exploratory programming while
> experimenting but in the library which is meant for production use
> behavior should be
> as predictable as possible.
> 
> Using "zero flags" means that the function might or might not block
> which pretty-much
> guarantees headaches later on when troubleshooting the code which will use it.
> 

Is there any reason that it isn't just called a single time on system
startup? It should never again block after that point in time. A
measurement that might be worth considering is if it blocks, ever, in
practice? At least one of my Debian systems appears to ensure that the
RNG is seeded before it has reached the run level where services run.
Might that be the case here? Might it also be possible to call the
wrapper for getrandom() at library init time as well as later when the
random bytes are needed?

> I think we should always opt for "least surprise" path and use
> GRND_NONBLOCK (as in
> current patch). That way we'll never block and let the caller handle
> errors (if any).

Isn't it more error prone to handle errors and unfilled buffers than to
block a single time? Seems tricky, though I agree that consistent
behavior might be worth the trade off. If GRND_NONBLOCK ensures that no
buffer is ever underfilled, that might be the middle ground that makes
the most sense.

> 
>> * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
> 
> I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
> /dev/random and /dev/urandom are going through the same CSPRNG so I'm
> not sure we
> gain anything by requiring random instead of urandom.
> 

That is my understanding as well. The key difference is that you were
spot on about the pool being drained very seriously - to the point of
underflowing, thus potentially encountering serious error states. Those
error states might be a 512 byte buffer with only one random byte, for
example.

Happy Hacking,
RS


From msuraev at sysmocom.de  Fri Oct  6 16:57:03 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 6 Oct 2017 18:57:03 +0200
Subject: prng change feedback
In-Reply-To: <3c4721d4cc628948ae898a1d4222387c@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
Message-ID: <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>

On 06.10.2017 17:43, ringsignature at riseup.net wrote:
> Is there any reason that it isn't just called a single time on system
> startup? It should never again block after that point in time.

Small clarification (more like not to myself reading this later on): that's the case
for default urandom source (used in current patch), not the GRND_RANDOM (discussed
elsewhere in the ML thread).

>  A measurement that might be worth considering is if it blocks, ever, in
> practice?

We'll sort of make that in the end: even in GRND_NONBLOCK mode the errno is set for
the cases where it would have been blocked otherwise. It's propagated to application
by osmo_get_rand_id() and the application will log it.

> Might it also be possible to call the
> wrapper for getrandom() at library init time as well as later when the
> random bytes are needed?

Sure, but it seems more complex.

What do we gain by using it that way? The underlying getrandom() call might still
fail so we have to handle/propagate errors anyway.
What do we loose by using it that way? Seems like nothing - see my note about error
propagation above.

> Isn't it more error prone to handle errors and unfilled buffers than to
> block a single time?

We don't have to deal with unfilled buffers in application code: either call to
osmo_get_rand_id() succeeds or not.

Also it depends on what kind of error handling we choose. To me single "if (rc < 0) {
log("doh!"); exit(1); }" looks less error-prone than potentially blocking code.

>  Seems tricky, though I agree that consistent
> behavior might be worth the trade off. If GRND_NONBLOCK ensures that no
> buffer is ever underfilled, that might be the middle ground that makes
> the most sense.

GRND_NONBLOCK doesn't guarantee that, using OSMO_MAX_RAND_ID_LEN = 16 and default urandom source does.

I think there might be some confusion so let me stress the following point: GRND_*
flags are independent. There are 2 flags currently available. So we have 4 flag
combinations.

GRND_RANDOM let us select randomness source.
GRND_NONBLOCK let us control blocking behavior.

So in the absence of explicit guarantees (provided by _NONBLOCK) we can implicitly
control blocking (to block at most once) by selecting random source and buffer size.

I prefer explicit control unless there are strong arguments against it.

> That is my understanding as well. The key difference is that you were
> spot on about the pool being drained very seriously - to the point of
> underflowing, thus potentially encountering serious error states. Those
> error states might be a 512 byte buffer with only one random byte, for
> example.

There're 2 possible causes for underfilled buffer after getrandom() according to man:
1) insufficient entropy

2) signal interrupt

Both are impossible in the current implementation under review in
https://gerrit.osmocom.org/#/c/1526/

1) Impossible because we use default urandom source

2) Impossible because we always request less than 256 bytes

I still check for it out of paranoia.

However, from application PoV it should not matter anyway: if call to some function
might fail than we should handle it. There are basically 2 things we can do after
logging the error:

- terminate the application

- fallback to insecure random numbers

So far we used the latter. If understood the summary of ongoing discussion right,
than we should opt for former. Shall I make it configurable via application
vty/config (OsmoBSC/OsmoMSC/OsmoSGSN)?

-- 
Max Suraev <msuraev at 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 






From ringsignature at riseup.net  Fri Oct  6 23:32:39 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Fri, 06 Oct 2017 16:32:39 -0700
Subject: prng change feedback
In-Reply-To: <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
Message-ID: <a7ff9091d58b6a113094335bcee2591b@riseup.net>

Hello,

On 2017-10-06 16:57, Max wrote:
> On 06.10.2017 17:43, ringsignature at riseup.net wrote:
>> Is there any reason that it isn't just called a single time on system
>> startup? It should never again block after that point in time.
> 
> Small clarification (more like not to myself reading this later on):
> that's the case
> for default urandom source (used in current patch), not the
> GRND_RANDOM (discussed
> elsewhere in the ML thread).
> 
>
>>  A measurement that might be worth considering is if it blocks, ever, in
>> practice?
> 
> We'll sort of make that in the end: even in GRND_NONBLOCK mode the
> errno is set for
> the cases where it would have been blocked otherwise. It's propagated
> to application
> by osmo_get_rand_id() and the application will log it.

OK. That seems reasonable as a way of measuring if this is practically a
problem on any production systems.

If such a log message occurs, what would it mean to an end user? One
might read that as those random bytes are less than ideal but beyond
that, I'm not sure what it would mean in an actionable sense. Does it
mean one shouldn't use an IMSI ki generated when that log message is
emitted?

>> Might it also be possible to call the
>> wrapper for getrandom() at library init time as well as later when the
>> random bytes are needed?
> 
> Sure, but it seems more complex.
> 

If there is a library setup, a possible, but not certain, blocking call
seems reasonable for the later promise of never blocking. It could even
call the same function with a single argument change? I agree that it is
slightly more complex, though I think the trade off might be worth
considering. Though it sounds like you have considered it and your
conclusions are all very reasonable. 

> What do we gain by using it that way? The underlying getrandom() call
> might still
> fail so we have to handle/propagate errors anyway.

The documentation explicitly claims to never fail for 1 to 256 byte
requests:

       If  the  urandom  source  has  been  initialized, reads of up to
256 bytes will always return as many bytes as
       requested and will not be interrupted by signals.  No such
guarantees apply  for  larger  buffer  sizes.   For
       example, if the call is interrupted by a signal handler, it may
return a partially filled buffer, or fail with
       the error EINTR.

> What do we loose by using it that way? Seems like nothing - see my
> note about error
> propagation above.

I think the failure on an embedded system is that the output is
predictable. That's the Mining Your Ps and Qs issue all over again with
GSM and related protocols. I'm curious about analysis of GSM and related
protocols, specifically how they fail when there isn't sufficient
entropy. Are there any useful survey papers on the topic that anyone
could recommend?

> 
>> Isn't it more error prone to handle errors and unfilled buffers than to
>> block a single time?
> 
> We don't have to deal with unfilled buffers in application code: either call to
> osmo_get_rand_id() succeeds or not.

Ah - of course, in your patch for values of 1 to 256 bytes, I agree. The
suggestion of using GRND_RANDOM does produce an occasional outcome where
the buffer is less than the requested size, which does need to be
handled. I think that for simplicity, it seems wise to avoid using
GRND_RANDOM, regardless of the discussion around GRND_NONBLOCK.
 
> Also it depends on what kind of error handling we choose. To me single
> "if (rc < 0) {
> log("doh!"); exit(1); }" looks less error-prone than potentially blocking code.

In the case of GRND_NONBLOCK, I generally agree.

>>  Seems tricky, though I agree that consistent
>> behavior might be worth the trade off. If GRND_NONBLOCK ensures that no
>> buffer is ever underfilled, that might be the middle ground that makes
>> the most sense.
> 
> GRND_NONBLOCK doesn't guarantee that, using OSMO_MAX_RAND_ID_LEN = 16
> and default urandom source does.

Understood, I agree that with GRND_NONBLOCK alone, getrandom() should
both never block and never under fill a buffer of 256 bytes or less.

> I think there might be some confusion so let me stress the following
> point: GRND_*
> flags are independent. There are 2 flags currently available. So we have 4 flag
> combinations.
> 
> GRND_RANDOM let us select randomness source.
> GRND_NONBLOCK let us control blocking behavior.
> 
> So in the absence of explicit guarantees (provided by _NONBLOCK) we
> can implicitly
> control blocking (to block at most once) by selecting random source
> and buffer size.
> 
> I prefer explicit control unless there are strong arguments against it.

I agree with the strategy of explicit control. Where we slightly diverge
is that I would simply want to ensure that the RNG was initialized. My
intuition is that on most modern systems, it will always be the case but
for some embedded systems, it seems to be tempting fate. In those
perhaps rare but perhaps serious cases, I think an initalizer function
blocking once might save a lot of cryptographic headaches later.

>> That is my understanding as well. The key difference is that you were
>> spot on about the pool being drained very seriously - to the point of
>> underflowing, thus potentially encountering serious error states. Those
>> error states might be a 512 byte buffer with only one random byte, for
>> example.
> 
> There're 2 possible causes for underfilled buffer after getrandom()
> according to man:
> 1) insufficient entropy
> 
> 2) signal interrupt
> 
> Both are impossible in the current implementation under review in
> https://gerrit.osmocom.org/#/c/1526/
> 
> 1) Impossible because we use default urandom source
> 
> 2) Impossible because we always request less than 256 bytes
> 

Yes, I agree.   

> I still check for it out of paranoia.

I'm not sure if this is portable to FreeBSD with the same guarantees, so
checking seems prudent.
 
> However, from application PoV it should not matter anyway: if call to
> some function
> might fail than we should handle it.

Agreed.

> There are basically 2 things we
> can do after
> logging the error:
> 
> - terminate the application
> 
> - fallback to insecure random numbers
> 
> So far we used the latter. If understood the summary of ongoing
> discussion right,
> than we should opt for former. 

It is certainly better to terminate than to use insecure random numbers
in the security sensitive context, especially if any of those bytes are
used for anything that is long lived.

The only other option is the one we've discussed and perhaps isn't worth
while: initialize once in a blocking manner such that the above
termination state should never happen in theory. Of course, you'll catch
it when it happens in practice when it is caused by for some previously
unconsidered factor. It might make sense to simply state that the OS
handles this case but [0] suggests that such an approach fails badly.
It's probably worse than the papers in public as those are simply the
systems that attract open research and attention.

Essentially, I think your conclusions are clear, and reasonable. I agree
with you and I still worry that I don't have a way to measure the
(probably obscure) failure case. I think this is actually a failure of
the /dev/urandom interface - is any option unsafe? If so, why does it
exist after so many years of failures from unsafe options?

> Shall I make it configurable via application
> vty/config (OsmoBSC/OsmoMSC/OsmoSGSN)?

If the default is reasonably secure, it doesn't seem necessary to add a
foot cannon.

Thank you for all your work on this patch set and for discussing it in
incredible detail.

Happy Hacking,
RS

[0] https://factorable.net/weakkeys12.extended.pdf


From laforge at gnumonks.org  Sat Oct  7 06:34:29 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 7 Oct 2017 14:34:29 +0800
Subject: prng change feedback
In-Reply-To: <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
Message-ID: <20171007063429.3fclizofkikc4f4p@nataraja>

Hi Max,

On Fri, Oct 06, 2017 at 06:57:03PM +0200, Max wrote:
> However, from application PoV it should not matter anyway: if call to some function
> might fail than we should handle it. There are basically 2 things we can do after
> logging the error:
> 
> - terminate the application
> 
> - fallback to insecure random numbers
> 
> So far we used the latter. If understood the summary of ongoing discussion right,
> than we should opt for former. Shall I make it configurable via application
> vty/config (OsmoBSC/OsmoMSC/OsmoSGSN)?

I think it should be a compile time decision for now, and the default
should be "no fallback".  So basically the entire fallback code is
#ifdef'd out unless somebody builds libosmocore with a possibly
dangerous compile option and has a good reason to do so.

If the user does that, there should be a related warning at the end of
the ./configure step, and we should also print runtime WARNING level
messages once we actually start to fallback to insecure rand().

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sat Oct  7 06:30:30 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 7 Oct 2017 14:30:30 +0800
Subject: prng change feedback
In-Reply-To: <3c4721d4cc628948ae898a1d4222387c@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
Message-ID: <20171007063030.3w5gowoinhhl6x56@nataraja>

Hi RS,

On Fri, Oct 06, 2017 at 08:43:22AM -0700, ringsignature at riseup.net wrote:
> >> * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
> > 
> > I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
> > /dev/random and /dev/urandom are going through the same CSPRNG so I'm
> > not sure we
> > gain anything by requiring random instead of urandom.
> > 
> 
> That is my understanding as well. The key difference is that you were
> spot on about the pool being drained very seriously - to the point of
> underflowing, thus potentially encountering serious error states. Those
> error states might be a 512 byte buffer with only one random byte, for
> example.

I don't think this is an issue. We can actually do blocking reads for
key generation, once we ever do that.  The speed of programming SIM
cards is probably invariably slower than the amount of randomness we can
get.  That's a one time operation at the time SIM cards are programmed.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ringsignature at riseup.net  Sat Oct  7 08:49:35 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Sat, 07 Oct 2017 08:49:35 +0000
Subject: prng change feedback
In-Reply-To: <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
Message-ID: <77f78a99175362a800dde2af8ec93aea@riseup.net>

On 2017-10-06 16:57, Max wrote:
> GRND_RANDOM let us select randomness source.
> GRND_NONBLOCK let us control blocking behavior.

After rereading the relevant documentation, I realize that I
misunderstood one critical point regarding GRND_NONBLOCK. The critical
difference is that GRND_NONBLOCK controls not only blocking behavior, it
also ensures that in the case of the system not being properly seeded,
it fails closed by immediately returning -1 without outputting any
random bytes. I apologize for completely missing this detail.

It is of course the case that you are correct and if blocking is a
problem, it is logical to set GRND_NONBLOCK and to handle the error
case, especially by terminating. That is indeed a critical error and
there should be no output.

Happy Hacking,
RS


From ringsignature at riseup.net  Sat Oct  7 09:18:46 2017
From: ringsignature at riseup.net (ringsignature at riseup.net)
Date: Sat, 07 Oct 2017 02:18:46 -0700
Subject: prng change feedback
In-Reply-To: <20171007063030.3w5gowoinhhl6x56@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <20171007063030.3w5gowoinhhl6x56@nataraja>
Message-ID: <2f10263a2c65b0f6630f32cc22af4d66@riseup.net>

On 2017-10-07 06:30, Harald Welte wrote:
> Hi RS,
> 
> On Fri, Oct 06, 2017 at 08:43:22AM -0700, ringsignature at riseup.net wrote:
>> >> * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
>> >
>> > I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
>> > /dev/random and /dev/urandom are going through the same CSPRNG so I'm
>> > not sure we
>> > gain anything by requiring random instead of urandom.
>> >
>>
>> That is my understanding as well. The key difference is that you were
>> spot on about the pool being drained very seriously - to the point of
>> underflowing, thus potentially encountering serious error states. Those
>> error states might be a 512 byte buffer with only one random byte, for
>> example.
> 
> I don't think this is an issue. We can actually do blocking reads for
> key generation, once we ever do that.  The speed of programming SIM
> cards is probably invariably slower than the amount of randomness we can
> get.  That's a one time operation at the time SIM cards are programmed.

That suggests setting GRND_NONBLOCK for all calls except for generation
of SIM card cryptographic keys, I think?

In the latter case, setting a flag of '0' may be appropriate. After
reading one of the latest [0] papers on the robustness of /dev/random, I
think it would be wise to leave GRND_RANDOM out and only use urandom in
a properly seeded state for such keys. That that paper does not inspire
confidence in even that choice, sadly I don't see a better choice.

Happy Hacking,
RS
[0] https://eprint.iacr.org/2013/338.pdf


From anindya.s at toshniwalcontrols.com  Sat Oct  7 11:39:47 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Sat, 7 Oct 2017 17:09:47 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171006142240.GB29730@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
Message-ID: <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>

Hello,

 I have freshly built it again from source from the osmocom repositories
and proceeded a little further and getting this folowing error.

lab at tecpl:~/dev/osmo-bsc/config$ osmo-bsc -c osmo-bsc.cfg
<002d> osmo_ss7.c:1229 0: ASP Restart for server not implemented yet!
% Ignoring deprecated logging level everything
<0021> telnet_interface.c:102 telnet at 127.0.0.1 4242
<0028> control_if.c:788 CTRL at 127.0.0.1 4249
<000a> osmo_bsc_sigtran.c:464 Initializing SCCP connection to MSC msc-0
<000a> osmo_bsc_sigtran.c:474 CS7 Instance identifier, A-Interface: 0
<002e> sccp_user.c:374 msc-0: Using SS7 instance 0, pc:0.23.3
<002e> sccp_user.c:398 msc-0: Using AS instance as-clnt-msc-0
<002e> sccp_user.c:403 msc-0: Creating default route
<0021> socket.c:258 unable to connect socket: (null):2905: Connection
refused
<002d> osmo_ss7.c:1215 0: Unable to open stream client for ASP
asp-clnt-msc-0
<002e> sccp_user.c:458 msc-0: Using ASP instance asp-clnt-msc-0
<002e> sccp_user.c:461 msc-0: Creating SCCP instance
<000a> osmo_bsc_sigtran.c:500 A-interface: invalid or missing local (BSC)
SCCP address (a.bsc_addr=RI=NONE,GTI=NO_GT)
<000a> osmo_bsc_sigtran.c:504 A-interface: using automatically generated
local (BSC) SCCP address
(a.bsc_addr=RI=SSN_PC,PC=0.23.3,SSN=BSSAP,GTI=NO_GT)
<000a> osmo_bsc_sigtran.c:518 A-interface: invalid or missing remote (MSC)
SCCP address for the MSC (a.msc_addr=RI=NONE,GTI=NO_GT)
<000a> osmo_bsc_sigtran.c:523 A-interface: using automatically generated
remote (MSC) SCCP address
(a.msc_addr=RI=SSN_PC,PC=0.23.1,SSN=BSSAP,GTI=NO_GT)
<000a> a_reset.c:155 (msc-0) reset handler fsm created.
<000a> a_reset.c:102 (msc-0) reset-ack timeout (T1234) in state ST_DISC
(disconnected), resending...
<000a> osmo_bsc_sigtran.c:94 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP,GTI=NO_GT
<002d> m3ua.c:505 XUA_AS(as-clnt-msc-0)[0x1dcef20]{AS_DOWN}: Event
AS-TRANSFER.req not permitted
<000a> a_reset.c:102 (msc-0) reset-ack timeout (T0) in state ST_DISC
(disconnected), resending...
<000a> osmo_bsc_sigtran.c:94 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP,GTI=NO_GT
<002d> m3ua.c:505 XUA_AS(as-clnt-msc-0)[0x1dcef20]{AS_DOWN}: Event
AS-TRANSFER.req not permitted
^Csignal 2 received


can you help me with it now... if you can tell me what I need to do.. As I
have mentioned the MSC address but still its giving address errors.

Thanks
Anindya

On Fri, Oct 6, 2017 at 7:52 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Thu, Oct 05, 2017 at 02:58:47PM +0530, Anindya Sankar Roy wrote:
> > Hello,
> >
> > I didnot build osmo-bsc from source rather I installed from ubuntu
> software
> > centre. I believe its the old one. But can you tell me why do I dont see
> > nothing when I try to filter pcap trace with SCCP, M2UA etc Can you tell
> me
> > what I might be missing out here.
>
> Unless you are using osmo-bsc packages from
> https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
> you are most definitely using SCCPlite, i.e. no M3UA and no SCTP.
>
> See
> https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
>
> We are still lacking in-depth (or any) documentation on the difference
> between
> SCCPlite and SCCP/M3UA.
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171007/bca4e16c/attachment.htm>

From nhofmeyr at sysmocom.de  Sun Oct  8 18:55:30 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 8 Oct 2017 20:55:30 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
Message-ID: <20171008185530.GA15349@my.box>

On Sat, Oct 07, 2017 at 05:09:47PM +0530, Anindya Sankar Roy wrote:
> <0021> socket.c:258 unable to connect socket: (null):2905: Connection
> refused
> <002d> osmo_ss7.c:1215 0: Unable to open stream client for ASP
> asp-clnt-msc-0

osmo-bsc cannot connect to the STP.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171008/71f05c91/attachment.bin>

From holger at freyther.de  Mon Oct  9 02:07:32 2017
From: holger at freyther.de (Holger Freyther)
Date: Mon, 9 Oct 2017 10:07:32 +0800
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171008185530.GA15349@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
Message-ID: <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>


> On 9. Oct 2017, at 02:55, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> On Sat, Oct 07, 2017 at 05:09:47PM +0530, Anindya Sankar Roy wrote:
>> <0021> socket.c:258 unable to connect socket: (null):2905: Connection
>> refused
>> <002d> osmo_ss7.c:1215 0: Unable to open stream client for ASP
>> asp-clnt-msc-0
> 
> osmo-bsc cannot connect to the STP.

and (null):2905 indicates that no host has been configured. ;)

holger


From laforge at gnumonks.org  Mon Oct  9 05:46:16 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Oct 2017 13:46:16 +0800
Subject: github.com mirrors for new post split-nitb repos
Message-ID: <20171009054616.khhmehrsjjgonnrx@nataraja>

Hi!

yesterday I saw that the github.com mirrors of the
osmo-{bsc,msc,hlr,mgw,sgsn,ggsn} repositories had not yet been created
so far.  We have mirrors on github so we can at times look at what
people are doing in public clones of the repositories.  This is useful
as in the 21st century, a lot of developers have to have adopted a
quality of "fork and never contribute back" attitude :/

In the past, we had to ask github staff to manually configure a mirror,
as this is not possible to do via their website for some reason.

It seems that this is now discouraged and they suggest to use a
post-receive hook that replicates to github.

I chose another path and used the already existing gerrit replication
plugin which we use to replicate form gerrit to git.osmocom.org. This
replication plugin is now also pushing to the respective github.com
mirrors.

I'm contacting github.com staff to convert all repositories to this
new-style setup.  This ensures the setup is identical for all mirrors,
and has the added benefit that we get quicker replication than the
once-per-hour poll.

The setup is documented at
https://osmocom.org/projects/osmocom-servers/wiki/Github_mirrors

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Oct  9 06:05:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Oct 2017 14:05:04 +0800
Subject: RF based RNG (was Re: prng change feedback)
In-Reply-To: <7be3802a05abd0a70b39fef23a6d74e8@riseup.net>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <d18bd3b1-3c8b-eae0-15a8-3d9c92888c94@sysmocom.de>
 <a1ad8822dcd5ba1a42aa4ac7c4778b9a@riseup.net>
 <20171006010323.zqxrck4ncoy6q4qx@nataraja>
 <7be3802a05abd0a70b39fef23a6d74e8@riseup.net>
Message-ID: <20171009060504.pnh3mipkg4wyohpf@nataraja>

Hi RS,

On Thu, Oct 05, 2017 at 11:16:45PM -0700, ringsignature at riseup.net wrote:
> Might those devices be interesting as a research target for generating
> entropy from a radio interface? The specification suggests that the
> device does indeed have a radio interface. If so, perhaps it would be a
> useful experiment for someone to attempt to create an OsmoEntropy
> subproject?

Technically, it would of course make sense, and conceptually it's a great
idea.  However, specifically on the sysmoBTS (as some other devices we support),
the proprietary PHY (and hence any part that directly obtains baseband
samples) runs on a separate DSP core.

On osmo-bts using that PHY we only have access to figures like BER,
RSSI, clock drift, burst arrival timing, ...  It might be possible to
use some of those for generating entropy, too - if proper care is taken
to avoid situations where all of those parameters are controlled by an
attacker, of course.

For devices using osmo-trx (the SDR based implementation of a GSM PHY),
the situation is different:  OsmoTRX receives the baseband samples and
is performing the radiomodem function on it.  osmo-bts-trx then performs
the bust demodulation/decoding.  One could hence possibly add some
module to either of the two (probably osmo-trx).

However, the much higher CPU requirements of a osmo-trx + osmo-bts-trx
setup require a larger/higher-end system (like embedded PC) to run the
related code, and hence the probability of having a hardware randomness
source is much higher than on the deeply embedded sysmoBTS or
osmo-bts-octphy / osmo-bts-litecell15 devices which all run a
proprietary PHY in a DSP.

> I would be interested in undertaking such a project, if it
> would be useful and especially if it would be used.

I think if it existed for osmo-bts-sysmo, we'd for sure use it.  I'm
still not sure if it's really worth the effort, given that most
non-trivial setups typically have an external computer as BSC/NITB
anyway, as stated below:

> > However, in most realistic scenarios you would have more than one BTS
> > and run the NITB/MSC/SGSN on some kind of (embedded?) x86 or ARM board,
> > and most systems have had hardware random number generators for quite a
> > long time.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From msuraev at sysmocom.de  Mon Oct  9 10:16:50 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 9 Oct 2017 12:16:50 +0200
Subject: prng change feedback
In-Reply-To: <20171007063429.3fclizofkikc4f4p@nataraja>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box> <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
 <20171007063429.3fclizofkikc4f4p@nataraja>
Message-ID: <092e7e20-0347-e739-4cc5-baa97e757c41@sysmocom.de>

I'm somewhat confused with the implementation details: placing fallback into library
would mean we effectively duplicate the fallback logic: the library might or might
not fallback and than the application will have to decide if it's ok with the fallback.

I'd prefer to use secure only random in the library code and make insecure fallback a
compile-time option in the application code. That way we can manage it on application
or even case-by-case basis later on if we decide to drop it altogether.

Although I might be missing smth, so looking forward for your feedback.

On 07.10.2017 08:34, Harald Welte wrote:
> I think it should be a compile time decision for now, and the default
> should be "no fallback".  So basically the entire fallback code is
> #ifdef'd out unless somebody builds libosmocore with a possibly
> dangerous compile option and has a good reason to do so.
>
> If the user does that, there should be a related warning at the end of
> the ./configure step, and we should also print runtime WARNING level
> messages once we actually start to fallback to insecure rand().
>

-- 
Max Suraev <msuraev at 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 






From laforge at gnumonks.org  Mon Oct  9 11:18:11 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Oct 2017 19:18:11 +0800
Subject: FYI: upstream asn1c progress
Message-ID: <20171009111811.bs4ozeqnvolr2f74@nataraja>

Hi all,

upstream asn1c (https://github.com/vlm/asn1c) has made significant
progress in 2017.  It now has basic support for information object
classes, and while doing some S1AP related test I also could compile an
unmodified RANAP ASN.1 syntax from osmo-iuh.git commit
8f2fb0cca5f990b26478e9ec1207fa1e39e691eb - i.e. before all the various
rewrites and hacks that we added to make it pass the much older asn1c
that we were using at the time.

In case anyone wants to play with this, I've had success with asn1c up
to git commit
https://github.com/vlm/asn1c/commit/e700b208bc0b252c85390a80ee63f3687fb2d970
until
https://github.com/vlm/asn1c/commit/ea6635bdae9667bcf6111a25d896c556c946c11a
unfortunately introduces a regression that's tracked in
https://github.com/vlm/asn1c/issues/185

Resolving that regression seems like it requires quite a bit of insight
into asn1c internals, which nobody in Osmocom currently has.

What's still missing from upstream is APER support.  Sadly, he
maintainer @vlm states clearly that APER is not a short-term goal for
him.  However, ss UPER is supported, and there's the somewhat incomplete
Eurecom/OAI hacks (with our fixes on top) as well as work in the
following pull-request https://github.com/vlm/asn1c/pull/125 I don't
think that's such a big issue anymore.  It would be best to create
somewhat of a test suite and then get the APER code up to a state until
it passes that test suite.  I'd be happy to put some of my (or sysmocom
developer) time into that.

But assuming that the regression parsing/compiling the ASN.1 syntax can
somehow be fixed, I think there's some clear "light at the end of the
tunnel" that we could compile the 3GPP syntax for RUA, HNBAP, RANAP and
S1AP as-is, without first rewriting it, and without the asn1tostruct.py
hack.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Oct  9 11:25:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Oct 2017 19:25:19 +0800
Subject: prng change feedback
In-Reply-To: <092e7e20-0347-e739-4cc5-baa97e757c41@sysmocom.de>
References: <414e491e3c9c40ba8e960611691aed90@riseup.net>
 <20171005110940.GA3133@my.box>
 <bf376d4ce985e95c43ab91cf64e27541@riseup.net>
 <20171006012321.nkomixxbodh4xha2@nataraja>
 <da583815-dd90-62d1-4845-dbb5b0f9e0b9@sysmocom.de>
 <3c4721d4cc628948ae898a1d4222387c@riseup.net>
 <dd94b2e8-1c94-d48a-94ae-dabea18cd1a8@sysmocom.de>
 <20171007063429.3fclizofkikc4f4p@nataraja>
 <092e7e20-0347-e739-4cc5-baa97e757c41@sysmocom.de>
Message-ID: <20171009112519.7rgdb3hpyico6o3y@nataraja>

On Mon, Oct 09, 2017 at 12:16:50PM +0200, Max wrote:
> I'm somewhat confused with the implementation details: placing fallback into library
> would mean we effectively duplicate the fallback logic: the library might or might
> not fallback and than the application will have to decide if it's ok with the fallback.
> 
> I'd prefer to use secure only random in the library code and make insecure fallback a
> compile-time option in the application code. That way we can manage it on application
> or even case-by-case basis later on if we decide to drop it altogether.

I think we should have the related code only once, and that means it should
be in the library.  I don't want per-application specific fallback.

In any case, to conserve our limited development resources, let's not have
any fallback for the time being and wait if it ever turns out to be an issue
for any of our users.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From pespin at sysmocom.de  Mon Oct  9 12:04:55 2017
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 9 Oct 2017 14:04:55 +0200
Subject: osmo-bts-trx fails frequently on osmo-gsm-tester
In-Reply-To: <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de>
References: <20170623025107.GE7792@my.box>
 <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box>
 <CAATyM+bz+a6KViv7=FwMicpD+KefG2KfrVz7mOqn8z96myCk9g@mail.gmail.com>
 <20170705101313.GB5921@my.box>
 <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de>
 <20170707005936.GB9089@my.box>
 <CAATyM+ZQ17p1WsPdX5NvHOc2hbMNS-A9ss+tw8MPtiA9N1Rd4Q@mail.gmail.com>
 <b889f839-7453-027f-7ebf-9fb4ede7fc2c@sysmocom.de>
 <20170710095935.GA32278@my.box>
 <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de>
Message-ID: <5b2718e4-2424-d5e4-b25e-012bf940f38d@sysmocom.de>

Hi everybody,

On 10/07/17 17:59, Pau Espin Pedrol wrote:
> Indeed, that was not the root cause for the issue I already fixed in 
> osmo-trx, which was the most common issue, but I'm still not sure about 
> the other one we are still facing, I need to look into it.
> 

After storing output from several test failures in osmo-gsm-tester using 
a B200, I was able to reduce the scope of the issue into osmo-trx / UHD 
/ B200 HW.

Please find the related information in this task comment:
https://osmocom.org/issues/2325#note-34

I would really appreciate help from anybody with a better knowledge on 
UHD and B200 HW to provide some feedback or advises on how to proceed here.

-- 
- Pau Espin Pedrol <pespin at 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


From djks74 at gmail.com  Mon Oct  9 12:42:47 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 9 Oct 2017 19:42:47 +0700
Subject: osmo-bts-trx fails frequently on osmo-gsm-tester
In-Reply-To: <5b2718e4-2424-d5e4-b25e-012bf940f38d@sysmocom.de>
References: <20170623025107.GE7792@my.box>
 <20170623091910.5odlmpwbdv2h5ddw@nataraja>
 <20170625132206.GA9557@my.box>
 <CAATyM+bz+a6KViv7=FwMicpD+KefG2KfrVz7mOqn8z96myCk9g@mail.gmail.com>
 <20170705101313.GB5921@my.box>
 <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de>
 <20170707005936.GB9089@my.box>
 <CAATyM+ZQ17p1WsPdX5NvHOc2hbMNS-A9ss+tw8MPtiA9N1Rd4Q@mail.gmail.com>
 <b889f839-7453-027f-7ebf-9fb4ede7fc2c@sysmocom.de>
 <20170710095935.GA32278@my.box>
 <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de>
 <5b2718e4-2424-d5e4-b25e-012bf940f38d@sysmocom.de>
Message-ID: <CANWiJYgWJSYFzjEa43OmSRcH_6RitAoYqYWjasQ9ukBGGZ1WQQ@mail.gmail.com>

Im working fine osmo-bts-trx with UHD 3.10.2, never install UHD from apt
install,
my advice is remove all UHD from apt install then rebuid it fresh from the
source code.
hope this help!

On Mon, Oct 9, 2017 at 7:04 PM, Pau Espin Pedrol <pespin at sysmocom.de> wrote:

> Hi everybody,
>
> On 10/07/17 17:59, Pau Espin Pedrol wrote:
>
>> Indeed, that was not the root cause for the issue I already fixed in
>> osmo-trx, which was the most common issue, but I'm still not sure about the
>> other one we are still facing, I need to look into it.
>>
>>
> After storing output from several test failures in osmo-gsm-tester using a
> B200, I was able to reduce the scope of the issue into osmo-trx / UHD /
> B200 HW.
>
> Please find the related information in this task comment:
> https://osmocom.org/issues/2325#note-34
>
> I would really appreciate help from anybody with a better knowledge on UHD
> and B200 HW to provide some feedback or advises on how to proceed here.
>
> --
> - Pau Espin Pedrol <pespin at 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
>



-- 
best regards,
Krazy Sandi
Blue Soho Recordings
Number One Recordings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171009/83ca646a/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Oct  9 13:37:00 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 9 Oct 2017 15:37:00 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
Message-ID: <20171009133700.GA31761@my.box>

On Mon, Oct 09, 2017 at 10:07:32AM +0800, Holger Freyther wrote:
> > On Sat, Oct 07, 2017 at 05:09:47PM +0530, Anindya Sankar Roy wrote:
> >> <0021> socket.c:258 unable to connect socket: (null):2905: Connection
> >> refused

> and (null):2905 indicates that no host has been configured. ;)

Which is a bit weird, because 127.0.0.1 should be the default...
Could you share your .cfg file?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171009/55f7c188/attachment.bin>

From laforge at gnumonks.org  Mon Oct  9 15:37:33 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Oct 2017 23:37:33 +0800
Subject: osmo-bts-trx fails frequently on osmo-gsm-tester
In-Reply-To: <CANWiJYgWJSYFzjEa43OmSRcH_6RitAoYqYWjasQ9ukBGGZ1WQQ@mail.gmail.com>
References: <CAATyM+bz+a6KViv7=FwMicpD+KefG2KfrVz7mOqn8z96myCk9g@mail.gmail.com>
 <20170705101313.GB5921@my.box>
 <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de>
 <20170707005936.GB9089@my.box>
 <CAATyM+ZQ17p1WsPdX5NvHOc2hbMNS-A9ss+tw8MPtiA9N1Rd4Q@mail.gmail.com>
 <b889f839-7453-027f-7ebf-9fb4ede7fc2c@sysmocom.de>
 <20170710095935.GA32278@my.box>
 <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de>
 <5b2718e4-2424-d5e4-b25e-012bf940f38d@sysmocom.de>
 <CANWiJYgWJSYFzjEa43OmSRcH_6RitAoYqYWjasQ9ukBGGZ1WQQ@mail.gmail.com>
Message-ID: <20171009153733.ac4377hps3gupxv3@nataraja>

Hi Sandi,

On Mon, Oct 09, 2017 at 07:42:47PM +0700, Sandi Suhendro wrote:
> Im working fine osmo-bts-trx with UHD 3.10.2, never install UHD from apt
> install, my advice is remove all UHD from apt install then rebuid it fresh from the source code.
> hope this help!

Thanks for your feedback.  However, this is nothing but a work-around and no
solution to the problem.

* application software like osmo-trx should work with any version of UHD
  that it successfully builds against

* if there are some specific bugs in the UHD versions that are shipped by
  stable/actively maintained distributions, then  related patches have to be
  submitted to the package maintainers in those distributions

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From anindya.s at toshniwalcontrols.com  Tue Oct 10 05:36:45 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 10 Oct 2017 11:06:45 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171009133700.GA31761@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box>
Message-ID: <CAAj2SE0GdWb-fnPqfiQn4ouUOZh13oQKz+88jff4Hhtn4Ox-1g@mail.gmail.com>

Hello,

 Ya sure I am attacking my cgf file , it would be also nice if you could
send me a standard one or the one you are using so I can get some Idea.

Thanks
Anindya

On Mon, Oct 9, 2017 at 7:07 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Mon, Oct 09, 2017 at 10:07:32AM +0800, Holger Freyther wrote:
> > > On Sat, Oct 07, 2017 at 05:09:47PM +0530, Anindya Sankar Roy wrote:
> > >> <0021> socket.c:258 unable to connect socket: (null):2905: Connection
> > >> refused
>
> > and (null):2905 indicates that no host has been configured. ;)
>
> Which is a bit weird, because 127.0.0.1 should be the default...
> Could you share your .cfg file?
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171010/82111278/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.cfg
Type: application/octet-stream
Size: 2755 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171010/82111278/attachment.obj>

From nhofmeyr at sysmocom.de  Tue Oct 10 13:46:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 10 Oct 2017 15:46:48 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE0GdWb-fnPqfiQn4ouUOZh13oQKz+88jff4Hhtn4Ox-1g@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box>
 <CAAj2SE0GdWb-fnPqfiQn4ouUOZh13oQKz+88jff4Hhtn4Ox-1g@mail.gmail.com>
Message-ID: <20171010134648.GE2043@my.box>

Hi Anindya,

I can successfully start osmo-bsc with your config file. It connects to
osmo-stp on 127.0.0.1 fine.

I can reproduce the "(null)" in my logs if I don't start osmo-stp.
Are you sure that you've started osmo-stp?

An (unrelated) curiosity is that you have no BTS configured.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171010/38e7404d/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct 10 13:52:32 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 10 Oct 2017 15:52:32 +0200
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171009133700.GA31761@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box>
Message-ID: <20171010135232.GF2043@my.box>

On Mon, Oct 09, 2017 at 03:37:00PM +0200, Neels Hofmeyr wrote:
> > >> <0021> socket.c:258 unable to connect socket: (null):2905: Connection
> > >> refused
> 
> > and (null):2905 indicates that no host has been configured. ;)
> 
> Which is a bit weird, because 127.0.0.1 should be the default...

About that (null), it comes up due to interna of osmo_sock_init2(). The
remote_host == NULL is passed to getaddrinfo(node) to yield the loopback
interface, and error reporting does not bother to replace that NULL.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171010/edf61abc/attachment.bin>

From djks74 at gmail.com  Tue Oct 10 20:13:41 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 11 Oct 2017 03:13:41 +0700
Subject: osmo-bts-trx fails frequently on osmo-gsm-tester
In-Reply-To: <20171009153733.ac4377hps3gupxv3@nataraja>
References: <CAATyM+bz+a6KViv7=FwMicpD+KefG2KfrVz7mOqn8z96myCk9g@mail.gmail.com>
 <20170705101313.GB5921@my.box>
 <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de>
 <20170707005936.GB9089@my.box>
 <CAATyM+ZQ17p1WsPdX5NvHOc2hbMNS-A9ss+tw8MPtiA9N1Rd4Q@mail.gmail.com>
 <b889f839-7453-027f-7ebf-9fb4ede7fc2c@sysmocom.de>
 <20170710095935.GA32278@my.box>
 <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de>
 <5b2718e4-2424-d5e4-b25e-012bf940f38d@sysmocom.de>
 <CANWiJYgWJSYFzjEa43OmSRcH_6RitAoYqYWjasQ9ukBGGZ1WQQ@mail.gmail.com>
 <20171009153733.ac4377hps3gupxv3@nataraja>
Message-ID: <CANWiJYiTTg993dkP7i7U5naaLWb0ZrP9gou3UscFrahv7uaWdw@mail.gmail.com>

I know it will work fine with any version with UHD, cause my self tried
many version of UHD and seems ok.
what I mean is  the installation of UHD.....
just in case, some people just use libuhd from apt install as example :

- sudo apt-get install uhd-host libuhd003 libuhd-dev

you need to remove all uhd-host and libuhd-dev then re-install from the source.


hope some one with good knowledge of UHD will tell us the problem with
HW and UHD driver with osmo-trx.



cheers,

DUO


On Mon, Oct 9, 2017 at 10:37 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sandi,
>
> On Mon, Oct 09, 2017 at 07:42:47PM +0700, Sandi Suhendro wrote:
> > Im working fine osmo-bts-trx with UHD 3.10.2, never install UHD from apt
> > install, my advice is remove all UHD from apt install then rebuid it
> fresh from the source code.
> > hope this help!
>
> Thanks for your feedback.  However, this is nothing but a work-around and
> no
> solution to the problem.
>
> * application software like osmo-trx should work with any version of UHD
>   that it successfully builds against
>
> * if there are some specific bugs in the UHD versions that are shipped by
>   stable/actively maintained distributions, then  related patches have to
> be
>   submitted to the package maintainers in those distributions
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>



-- 
best regards,
Krazy Sandi
Blue Soho Recordings
Number One Recordings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171011/d30e81f2/attachment.htm>

From anindya.s at toshniwalcontrols.com  Wed Oct 11 07:28:35 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Wed, 11 Oct 2017 12:58:35 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171010135232.GF2043@my.box>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box> <20171010135232.GF2043@my.box>
Message-ID: <CAAj2SE1P1pHvMu1ZY6WLgfEstnv_QE9QQnwQx1OHHJk-A6xDJg@mail.gmail.com>

Hello,

 Yes I did start osmo-stp but can you please tell me how to configure the
osmo-stp port ? I am just thinking that maybe that is the reason why its
not starting.
  By the way can you please share your cfg file, I would want to take a
look at it and see if I am missing anything.

I also tried to configure * bsc-addr                  Calling Address
(local address of this BSC)*  inside *OsmoBSC(config-msc)#*
but not sure what I must set the SCCP NAME as.

Thanks
Anindya

On Tue, Oct 10, 2017 at 7:22 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Mon, Oct 09, 2017 at 03:37:00PM +0200, Neels Hofmeyr wrote:
> > > >> <0021> socket.c:258 unable to connect socket: (null):2905:
> Connection
> > > >> refused
> >
> > > and (null):2905 indicates that no host has been configured. ;)
> >
> > Which is a bit weird, because 127.0.0.1 should be the default...
>
> About that (null), it comes up due to interna of osmo_sock_init2(). The
> remote_host == NULL is passed to getaddrinfo(node) to yield the loopback
> interface, and error reporting does not bother to replace that NULL.
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171011/3a635a7a/attachment.htm>

From laforge at gnumonks.org  Wed Oct 11 07:36:32 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 11 Oct 2017 15:36:32 +0800
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE1P1pHvMu1ZY6WLgfEstnv_QE9QQnwQx1OHHJk-A6xDJg@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box> <20171010135232.GF2043@my.box>
 <CAAj2SE1P1pHvMu1ZY6WLgfEstnv_QE9QQnwQx1OHHJk-A6xDJg@mail.gmail.com>
Message-ID: <20171011073632.xmx7npdw7fcc2m7d@nataraja>

On Wed, Oct 11, 2017 at 12:58:35PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
>  Yes I did start osmo-stp but can you please tell me how to configure the
> osmo-stp port ? I am just thinking that maybe that is the reason why its
> not starting.
>   By the way can you please share your cfg file, I would want to take a
> look at it and see if I am missing anything.

all osmocom projects come with "reasonable" example configuration files,
typically in the "doc/examples" folder.  Starting osmo-bsc, osmo-msc and osmo-stp
with those example configs on the same machine should render a setup in
which BSC and MCS connect to the STP and can exchange BSSAP messages between
them.

If you experience problems, please provide _proper_ reports, including your
config files, the log/stderr output as well as a pcap protocol trace of the relevan
communication (M3UA on loopback device in case of running all programs on one machine).

https://media.ccc.de/v/osmocon17-4008-reporting_and_investigating_issues_in_osmocom
also provides some help on what kind of information is required.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From msuraev at sysmocom.de  Fri Oct 13 09:57:51 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 13 Oct 2017 11:57:51 +0200
Subject: libosmo-netif interface
Message-ID: <22fabe0d-7971-2a9c-5156-7cd25a77f7e0@sysmocom.de>

Hi.

While looking at osmocom/netif/datagram.h I've noticed that it's organized
differently compared to other libosmo*. Most notably, it does not have structure
definitions, only brief declarations in datagram.h while the actual definition is in
datagram.c

This effectively means that client code using the library do not have access to
struct internals and have to use various "osmo_dgram_.x_set_*()" functions to
manipulate them.

This got me curious - what are the pros and cons of this approach?

I can see the benefit of being able to change struct internals without changing the
API. I can also see the downside in having to define lot's of boilerplate
setter/getter functions.

What else?

Are there other nice things about this approach? Is there a way to avoid or at least
simplify setter/getter boilerplate? Are there some other downsides to this?

-- 
Max Suraev <msuraev at 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 






From laforge at gnumonks.org  Sat Oct 14 06:01:40 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 14 Oct 2017 08:01:40 +0200
Subject: Planning for OsmoCon + OsmoDevCon
Message-ID: <20171014060140.khxczgit4pe2icuq@nataraja>

[cross-post to many lists, please follow-up-to openbsc at lists.osmocom.org]

Dear all,

time is flying, and I would like to start early with discussions and planning
about OsmoCon and OsmoDevCon in 2018.  It helps to start early.

Side note: We have some pending issues about the events from last year at
http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them
in the text below.


== OsmoDevCon ==

For OsmoDevCon, I think it's easy: We keep it as-is.  Same procedure as
every year, which means:
* same venue, same catering options
* same concept of 'anyone contributing to Osmocom can apply for
  registration until all seats are taken'
* same idea of inviting some few speaker[s] doing other FOSS mobile
  communications work to join us

The parts that we need to change, IMHO:

* don't reduce from 4 to 3 days like last year. Have full 4 days again
* sort topics per day / half-day, i.e. have "GSM/UMTS Cellular
  Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co,
  but then have other days for other projects.  This would enable people
  not interested in the [continued evolvement] of the cellular projects
  be able to skip those days, or to simply meet in an adjacent room for
  parallel hacking sessions/discussions
* try to be a bit more structured with the schedule in general. The
  existing approach works for people who attend all the event all day
  long, but not so well for people with other plans / limited time

Any further change requests or topics to discuss?

Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
Seville (Spain).  I've attended a number of netfilter workshops he
organized there, and he's doing a great job!  However, given the large
number of attendees from Berlin (and Germany in general), I think this
would make things more complicated, and more expensive for most
attendees.  If you disagree with that assessment: I'm open for having
the discussion, I just thought it's more practical/economic to do it in
Berlin.

=== 10 year Anniversary Party ===

Given that 2018 marks the 10 year anniversary of Dieter and me hacking
with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves
some special celebration of some form.  I have no concrete idea yet, but
for sure we should so something, and it should be at/around
OsmoDevCon.  And for sure we should have a BS-11 around :)


== OsmoCon ==

The public OsmoCon was welcomed and was a success.  However,
let's start this discussion with a review of last years event.

=== Registration ===

* Registrations came in way too late. Two weeks ahead of the event, we were
  considering to cancel it.  And then within the last few days, we had
  to turn people down due to limited seating capacity

* To make planning more reliable, we see on other option but to
  significantly raise the registration fee combined with an equally
  significant discount for early booking

=== Duration ===

* Many people requested multiple days rather than just one, in order to
  make more out of (long distance) travels.  This is obvious, but as we
  had no idea how many people would attend at all (or if we have to
  cancel due to lack of attendance), planning multiple days in the first
  incarnation would have been high risk and a multitude of work

* I would suggest to expand to two or even three days this week,
  possibly one days with tutorials and the other day with tech talks

* Slightly less crammed schedule due to multiple days

=== Venue ===

We recognize this yearso venue was not the best option, due to
* Bad ventilation in the basemenet
* Difficult to find
* No space next to the conference room where people can meet / hang out
  in parallel to talks (not everyone attends every talk)

I still like the "understatement" of the venue.  I'd prefer any hostel /
non-profit / hackerspace / university over luxurious hotels any time.
Going to an expensive venue means more or less automatically more
expensive ticket fees, which again is more likely to exclude pure
community members without a commercial activity related to Osmocom.

So any future venue would ideally:

* be able to hold slightly more people than this year
* have a second room or large lobby in which people can meet for
  extended coffee breaks in parallel to some talks, as needed
* be slightly easier to find (and we have to put up some signs outside
  and in the lobby)
* have better WiFi and/or wired connectivity

=== Programme / Format ===

* less crammed over multiple days
* some more "interactive" formats were requested, for users to provide
  feedback to developers
* there was some discussion about topics / speakers in redmine last
  year, but not too much participation [until it was too late].
* I'd suggest a more formal CfP process with a submission deadline that
  allows us to publish a preliminary schedule long ahead of the event

=== Video Recordings ===

I think they were a big success, and it was a very big surprise that the
CCC Video Operations Center was volunteering to help such a small and
niche-interest event like OsmoCon.  We should make sure that we can
repeat this for 2018.


== Dates / Frequency ==

Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at
a full week for those of you who would like to attend both events.  But
then, I think the number of people attending both events is actually not
all that big.  Without checking the details, I think not more than half
of the OsmoDevCon attendees were attending OsmoCon.  I would expect that
tendency to remain or even increase.

I still think it's good to keep them back-to-back.

In terms of frequency,  I would actually suggest we move to a 6-month
cycle rather than a 12-month cycle.  There's a lot of development going
on at all time. I understand that not everyone is able to attend two
events just on Osmocom, especially if it's a spare time / hobby type
activity.  That's ok, I think there's no problem with attending either
of the two only, and catching up by video recordings and/or mail on the
other.

The qeustion is: Should that second event be developer-oriented or
user-oriented?  Or again both?  Any comments here?


Ok, that was a somewhat lengthy e-mail.  Please make sure to provide any
feedback you may have as early as possible, to increase the chances of
your feedback being reflected in the planning.

Happy hacking,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Sat Oct 14 18:24:26 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 14 Oct 2017 20:24:26 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171014060140.khxczgit4pe2icuq@nataraja>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
Message-ID: <20171014182426.GA2759@my.box>

On Sat, Oct 14, 2017 at 08:01:40AM +0200, Harald Welte wrote:
> * same venue, same catering options

Maybe we can improve the table situation -- in the main conference room, that
oval table by the sofa corner takes up a lot of space, so that it can be hard
to pass between the tables. If we could get smaller tabkle or tables and maybe
leave the oval one in the smaller room, we'd have more space to cross the room
as well as have a second room to sit in?

> * have better WiFi and/or wired connectivity

Air to breathe, clean water and internet!

> === Video Recordings ===
> 
> We should make sure that we can repeat this for 2018.

No doubt, that was super excellent. I could also show my family what we're up
to :)

> == Dates / Frequency ==
> 
> Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
> OsmoCon is 2-3 days and OsmoDevCon is 4 days.

> I still think it's good to keep them back-to-back.

For me personally, being away from home early morning until late at night,
including the semi compulsory diner, for seven days in a row is a challenge.
Usually I feel that I should be present all of the time, but if it's seven full
days back to back I think I'd need to take some time off here and there. I'm
also expected to make up for offloading parenting responsibilites during the
event, so it seems a lot to extend OsmoCon by two days *and* add another
OsmoDevCon day. Three more days without a break?

OTOH I welcome more time to sprinkle some open socialising between talks, not
having to hush almost all conversations because the next talk is starting. For
long journeys taken to attend, it can be more convenient to not have to wait a
day between the events. But for being a tourist in Berlin, a day off in between
isn't that much either? What do travellers think about a day off halfway thru?
For me, being based in Berlin, that would be very convenient; I accept that
most others may differ... do you?

> The qeustion is: Should that second event be developer-oriented or
> user-oriented?  Or again both?  Any comments here?

My intuition is that once a year is plenty for a user oriented event with
talks. Two user based events a year may encourage attendants to spread over the
two events and thin out / not meet each other?

I imagine that offering workshops for smallish groups of users apart from a
larger event would make sense any time, as users may request them. We could
offer a dudle to coordinate good dates to hold workshops [1].

For hackers to meet, the more the better I guess.

~N

[1] https://dudle.inf.tu-dresden.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171014/c6ee1213/attachment.bin>

From keith at rhizomatica.org  Sun Oct 15 15:48:49 2017
From: keith at rhizomatica.org (Keith)
Date: Sun, 15 Oct 2017 10:48:49 -0500
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171014060140.khxczgit4pe2icuq@nataraja>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
Message-ID: <f092e2ad-d5a1-2383-46f3-35f129ae6e1c@rhizomatica.org>



On 14/10/2017 01:01, Harald Welte wrote:
>
> Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
> Seville (Spain).  I've attended a number of netfilter workshops he
> organized there, and he's doing a great job!  However, given the large
> number of attendees from Berlin (and Germany in general), I think this
> would make things more complicated, and more expensive for most
> attendees.  If you disagree with that assessment: I'm open for having
> the discussion, I just thought it's more practical/economic to do it in
> Berlin.

Yes, certainly for OsmoDevCon, Seville would mean travel and
expense for most.
?But how about the OsmoCon (assuming the decision was not to
have them back-to-back)?
I imagine that would mean a LOT more logistics work there,
maybe too much, like bringing CCC VOC for example.
?Were there to be any interest however, I tentatively raise
a hand to help out, including travelling pre event to Seville.

>
> === 10 year Anniversary Party ===
>
> Given that 2018 marks the 10 year anniversary of Dieter and me hacking
> with the Siemens BS-11 in 2008, 

:-)

> == OsmoCon ==
>
>
> In terms of frequency,  I would actually suggest we move to a 6-month
> cycle rather than a 12-month cycle.

Are you suggesting here to as an alternative to the
back-to-back? OsmoCon and OsmoDevCon,
to separate them with a six month interval? Or just to have
an OsmoCon every six months?





From laforge at gnumonks.org  Sun Oct 15 16:18:44 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 15 Oct 2017 18:18:44 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <f092e2ad-d5a1-2383-46f3-35f129ae6e1c@rhizomatica.org>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <f092e2ad-d5a1-2383-46f3-35f129ae6e1c@rhizomatica.org>
Message-ID: <20171015161844.b4pzuzpadgrasfc4@nataraja>

Hi Keith,

On Sun, Oct 15, 2017 at 10:48:49AM -0500, Keith wrote:
> Yes, certainly for OsmoDevCon, Seville would mean travel and
> expense for most.
> ?But how about the OsmoCon (assuming the decision was not to
> have them back-to-back)?

Possible, but I'm not sure if Pablo was volunteering for a significantly
larger event: OsmoCon was 60 people this year, so I would expect it to
be at least that same size next year.

> I imagine that would mean a LOT more logistics work there,
> maybe too much, like bringing CCC VOC for example.

Indeed.

> > In terms of frequency,  I would actually suggest we move to a 6-month
> > cycle rather than a 12-month cycle.
> 
> Are you suggesting here to as an alternative to the
> back-to-back? OsmoCon and OsmoDevCon,
> to separate them with a six month interval? Or just to have
> an OsmoCon every six months?

I'm open to all suggestions.  But indeed, for OsmoDevCon I think a 6
month cycle would be great - maybe at the very least for people involvd
in those projects with lots of development activity, such as currently
Osmo{BTS,PCU,BSC,MSC,MGW,STP,GGSN,HLR}.

For OsmoCon: Annual schedule is probably sufficient.  Nevetheless,
there's a lot of user-visible changes happening with the NITB-split, so
this year it would actually have made sense to do some updates.  

But as (I believe) Neels suggested, we could always propose something
like a workshop / tutorial and see if people are interested in that.
Such tutorials could actually also be a "webcast" or the like, without
physcial attendance.  This would remove the burden of travel and the
venue organization bits on our side.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Oct 15 16:27:35 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 15 Oct 2017 18:27:35 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171014182426.GA2759@my.box>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <20171014182426.GA2759@my.box>
Message-ID: <20171015162735.x5duufxu3sjaxlpp@nataraja>

Hi Neels,

On Sat, Oct 14, 2017 at 08:24:26PM +0200, Neels Hofmeyr wrote:
> Maybe we can improve the table situation -- in the main conference room, that
> oval table by the sofa corner takes up a lot of space, so that it can be hard
> to pass between the tables. If we could get smaller tabkle or tables and maybe
> leave the oval one in the smaller room, we'd have more space to cross the room
> as well as have a second room to sit in?

This has been a bottleneck for years, but in terms of tables we have to
stick with what the venue has, or we have to arrange for logistics of
transporting bulky objects around.  Maybe we could see if there are some
suitably foldable conference tables, and then buy them + donate them to
IN-Berlin (so we can use them each year, and they can be stored
meanwhile without using up too much space.  Do you want to investigate
that option, together with Heike + IN-Berlin?

> > == Dates / Frequency ==
> > 
> > Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
> > OsmoCon is 2-3 days and OsmoDevCon is 4 days.
> 
> > I still think it's good to keep them back-to-back.
> 
> For me personally, being away from home early morning until late at night,
> including the semi compulsory diner, for seven days in a row is a challenge.

I fully understand that.  But then, the question is whether you'd need
to be present all times.  As indicated, for OsmoDevCon I would want to
split the "cellular infrastructure" talks on some days and the other
topics like satellite/sdr/... on some other days.  So the 4 days would
become two days.

> Usually I feel that I should be present all of the time, but if it's seven full
> days back to back I think I'd need to take some time off here and there. I'm
> also expected to make up for offloading parenting responsibilites during the
> event, so it seems a lot to extend OsmoCon by two days *and* add another
> OsmoDevCon day. Three more days without a break?

OsmoDevCon clearly needs to get back the one day it lost this year.  At
least that was my feeling.  Do others agree?

More day[s] for OsmoCon was a clear request from many attendees.

> OTOH I welcome more time to sprinkle some open socialising between talks, not
> having to hush almost all conversations because the next talk is starting. For
> long journeys taken to attend, it can be more convenient to not have to wait a
> day between the events. But for being a tourist in Berlin, a day off in between
> isn't that much either? What do travellers think about a day off halfway thru?

I'll leave it to the non-Berlin-local folks to comment to that.

In general, I think the amount of overlap in terms of attendance would
nto be too big.  So maybe *not* having it back-to-back is actually a
good idea?

> My intuition is that once a year is plenty for a user oriented event with
> talks. 

See my other mail.  I think the amount of user-visible changes we're
introducing in the last months has prompted me to think about it.

> Two user based events a year may encourage attendants to spread over
> the two events and thin out / not meet each other?

possibly.

> I imagine that offering workshops for smallish groups of users apart from a
> larger event would make sense any time, as users may request them. We could
> offer a dudle to coordinate good dates to hold workshops [1].

Yes, or simply do some web/screencast or whatever form of "online only"
update every few months.  "Migrating from NITB to BSC+MSC+HLR" would be
a very good first topic currently, I suppose :)

> For hackers to meet, the more the better I guess.

Ok, then let's aim for two OsmoDevCon's next year.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Oct 15 16:30:09 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 15 Oct 2017 18:30:09 +0200
Subject: libosmo-netif interface
In-Reply-To: <22fabe0d-7971-2a9c-5156-7cd25a77f7e0@sysmocom.de>
References: <22fabe0d-7971-2a9c-5156-7cd25a77f7e0@sysmocom.de>
Message-ID: <20171015163009.2g4vlcgqjg57fo53@nataraja>

Hi Max,

On Fri, Oct 13, 2017 at 11:57:51AM +0200, Max wrote:

> While looking at osmocom/netif/datagram.h I've noticed that it's organized
> differently compared to other libosmo*. Most notably, it does not have structure
> definitions, only brief declarations in datagram.h while the actual definition is in
> datagram.c

This is correct.  It's probably following the kind of learning curve that Pablo
was making with netfilter related libraries over time.

> This effectively means that client code using the library do not have access to
> struct internals and have to use various "osmo_dgram_.x_set_*()" functions to
> manipulate them.

correct.

> This got me curious - what are the pros and cons of this approach?
> 
> I can see the benefit of being able to change struct internals without changing the
> API. I can also see the downside in having to define lot's of boilerplate
> setter/getter functions.

I think that's about it.  If you want to keep a long-term stable ABI +
API, then hiding the structure is the only sane approach.  But yes, it
comes at a cost.

> Is there a way to avoid or at least simplify setter/getter
> boilerplate?

I think it's called C++ with its ability to have private/friend/public members ;)

In C, I'm not aware of any simplification.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Mon Oct 16 12:13:14 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 16 Oct 2017 14:13:14 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171015162735.x5duufxu3sjaxlpp@nataraja>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <20171014182426.GA2759@my.box>
 <20171015162735.x5duufxu3sjaxlpp@nataraja>
Message-ID: <20171016121314.GA11071@my.box>

On Sun, Oct 15, 2017 at 06:27:35PM +0200, Harald Welte wrote:
> Ok, then let's aim for two OsmoDevCon's next year.

One in week 23, one in week 42 ;)

Reflecting on that, let's ask:

Who would / would not like to attend a second OsmoDevCon, generally?
It's not a problem really to have two smaller events, would just be interesting
to know if we would likely see everyone at both or not.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171016/f072ba56/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 16 12:26:31 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 16 Oct 2017 14:26:31 +0200
Subject: log level everything
In-Reply-To: <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
 <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
Message-ID: <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>

Hi.

Pardon for reviving such an old thread - I've stumbled upon this while reviewing
https://osmocom.org/issues/71 and there seems to be no definite conclusion as to what
shall we implement and how.

On 12.09.2017 10:55, Keith wrote:
> NOTE! I have my libosmocore patch in my original post on
> this thread in place, so I can still do log level all
> everything.

Does it work the same way (modulo "everything" option) on libosmocore from master?

> Here the specific per-subsystem levels were not
> respected, rather they were over-ridden by the logging all
> directive.

It seems like this have more to do with priorities rather than "everything" option:
shall the "logging level all XX" override the already set "logging level cc YY"? In
the existing manuals we do not document this either way which is an oversight which
shall be fixed. But before that we should agree on what's the expected behavior.

> It is impossible to silence a subsystem when logging level
> all has been issued.
> I am only able to achieve this with logging
> level all everything - This is the key to respecting the
> per-subsystem levels.

It seems somewhat confusing when trying to follow interactive session. Could you
please make an example .cfg which demonstrates the issue you're facing and attach it
to https://osmocom.org/issues/71 alongside with the incorrect output?

-- 
Max Suraev <msuraev at 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 






From sudhanthiradasan.r at hcl.com  Mon Oct 16 12:54:54 2017
From: sudhanthiradasan.r at hcl.com (Sudhanthiradasan R)
Date: Mon, 16 Oct 2017 12:54:54 +0000
Subject: Location Update Error
Message-ID: <HKNPR0401MB18414A9F2254440B6621FE74944F0@HKNPR0401MB1841.apcprd04.prod.outlook.com>

Hello,

I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM"

<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5
<0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS.
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION
<0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE
<0002> gsm_04_08.c:596 Location Updating Request procedure timedout.
<0002> gsm_04_08.c:474 Subscriber 901550000001016: LOCATION UPDATING REJECT LAC=1 BTS=0
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS.


Anyone had the same issue earlier? Is there any solution for this error?


Thanks,
Sudhanthiradasan R


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171016/11a28643/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Oct 16 13:10:27 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 16 Oct 2017 15:10:27 +0200
Subject: log level everything
In-Reply-To: <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
 <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
 <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>
Message-ID: <20171016131027.GA12221@my.box>

On Mon, Oct 16, 2017 at 02:26:31PM +0200, Max wrote:
> Hi.
> 
> Pardon for reviving such an old thread - I've stumbled upon this while reviewing
> https://osmocom.org/issues/71 and there seems to be no definite conclusion as to what
> shall we implement and how.

It's a good thing to re-raise lost topics.  We'll probably keep raising this
one until one of us sits down and churns out all of the details of a fix
everyone agrees with...

I can't remember in detail anymore what was wrong about 'logging all
everything', but it was definitely not what I expected. I might have been
wrong, too. At this point I guess we have to:

- from all logging related mails and posts, collect use cases of what we want
  to be able to do.
- look at the code to see whether we cover those and how.
- write documentation, possibly submit patches.

I can't do this at the moment...

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171016/d074053f/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 16 13:39:43 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 16 Oct 2017 15:39:43 +0200
Subject: Location Update Error
In-Reply-To: <HKNPR0401MB18414A9F2254440B6621FE74944F0@HKNPR0401MB1841.apcprd04.prod.outlook.com>
References: <HKNPR0401MB18414A9F2254440B6621FE74944F0@HKNPR0401MB1841.apcprd04.prod.outlook.com>
Message-ID: <20171016133943.GA18394@my.box>

On Mon, Oct 16, 2017 at 12:54:54PM +0000, Sudhanthiradasan R wrote:
> <0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE

What I can say is that you are receiving this error indication from the BTS and
need to investigate there. All that libbsc is doing is to log this error
indication received on the Abis interface.

> ::DISCLAIMER::

Please refrain from sending void legalese to public mailing lists. This mail
including the disclaimer is now part of a public mail archive and will not be
deleted; we refuse to obtain written consent of an authorized representative.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171016/d0f0b889/attachment.bin>

From laforge at gnumonks.org  Mon Oct 16 13:30:52 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 16 Oct 2017 15:30:52 +0200
Subject: log level everything
In-Reply-To: <20171016131027.GA12221@my.box>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
 <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
 <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>
 <20171016131027.GA12221@my.box>
Message-ID: <20171016133052.boivqzlpfpwpkyx2@nataraja>

My vote by now would actually be to simply remove this feature.  It seems
nobody has a common understanding of what it should do.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From msuraev at sysmocom.de  Mon Oct 16 13:50:37 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 16 Oct 2017 15:50:37 +0200
Subject: log level everything
In-Reply-To: <20171016133052.boivqzlpfpwpkyx2@nataraja>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
 <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
 <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>
 <20171016131027.GA12221@my.box> <20171016133052.boivqzlpfpwpkyx2@nataraja>
Message-ID: <0f8508c2-e295-9af1-df2e-76c5aeb45707@sysmocom.de>

Could you please clarify which feature exactly?
If it's "logging level all everything" than it's already removed as of
ed0eda236c525377e3c25d04456cbeafcab21c2d in libosmocore
If it's "logging level all" than I can make corresponding patch but I'm pretty sure
there will be requests to somehow set "default" logging level for all the categories
not configured explicitly.

On 16.10.2017 15:30, Harald Welte wrote:
> My vote by now would actually be to simply remove this feature.  It seems
> nobody has a common understanding of what it should do.


-- 
Max Suraev <msuraev at 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 






From keith at rhizomatica.org  Tue Oct 17 02:03:14 2017
From: keith at rhizomatica.org (Keith)
Date: Mon, 16 Oct 2017 21:03:14 -0500
Subject: log level everything
In-Reply-To: <20171016133052.boivqzlpfpwpkyx2@nataraja>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
 <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>
 <1e725b7d-4026-4bd6-ae61-4dcf359b4195@sysmocom.de>
 <20171016131027.GA12221@my.box> <20171016133052.boivqzlpfpwpkyx2@nataraja>
Message-ID: <f49b8b24-8616-e259-7616-1deb8914e9e2@rhizomatica.org>



On 16/10/2017 08:30, Harald Welte wrote:
> My vote by now would actually be to simply remove this feature. 
As I said before, I am currently finding that the "feature"
is missing, so therefore removing it is not a solution. :-/
The feature being: Select log levels to display individually.
Will follow up on the ticket.



From ron.menez at entropysolution.com  Tue Oct 17 04:57:17 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 17 Oct 2017 04:57:17 +0000
Subject: OSMO-BTS-TRX maxdly and maxdlynb Configuration Save issue
Message-ID: <BAD9FD7D-8B81-49C9-A5C2-C113C2DD3445@entropysolution.com>

Hi All,

We tried to edit the maxdly and maxdlynb in osmo-bts-trx through CLI and everything works fine.

But after saving the configuration and restarting the osmo-bts-trx instance, it give an unable to parse error.

The reason we found is that, the osmo-bts-trx needed the ?osmotrx maxdly 2? string to parse the config file correctly but the CLI config save is only ?maxdly 2?.

So we need to edit the config file manually so that the osmo-bts-trx can parse the config file correctly.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171017/7d81e996/attachment.htm>

From keith at rhizomatica.org  Tue Oct 17 05:12:04 2017
From: keith at rhizomatica.org (Keith)
Date: Tue, 17 Oct 2017 00:12:04 -0500
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171016121314.GA11071@my.box>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <20171014182426.GA2759@my.box> <20171015162735.x5duufxu3sjaxlpp@nataraja>
 <20171016121314.GA11071@my.box>
Message-ID: <997a37cd-b6be-100e-c6aa-d2f63f67bcd8@rhizomatica.org>



On 16/10/2017 07:13, Neels Hofmeyr wrote:
>
> Who would / would not like to attend a second OsmoDevCon, generally?
It really depends on where I end up living.

Let me say though, that if I knew there was just one
OsmoDevCon in April, then I would really try to avoid other
commitments for those dates.
However, if I had the option to choose between two, that
might make a difference, in allowing me to choose one.

Attending the Devcon has helped me greatly to "onboard" as a
beginner-developer ;-) and I think there is a lot more of
that going to be happening going forward, so other
restrictions aside, I would attend two.





From anindya.s at toshniwalcontrols.com  Tue Oct 17 06:36:26 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 17 Oct 2017 12:06:26 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <20171011073632.xmx7npdw7fcc2m7d@nataraja>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box> <20171010135232.GF2043@my.box>
 <CAAj2SE1P1pHvMu1ZY6WLgfEstnv_QE9QQnwQx1OHHJk-A6xDJg@mail.gmail.com>
 <20171011073632.xmx7npdw7fcc2m7d@nataraja>
Message-ID: <CAAj2SE0zKvnMHnP+qM7kdvoKxniaTQ-Jybj0LLhojGKYNH5tcw@mail.gmail.com>

Hello,

 I figured out my issue with the BSC to MSC link and have solved it, it was
actually the OPC DPC that caused all of it.
             Now I am working on Blade RF (SDR) to build the bsc ... I have
installed osmoSDR and now while I am building osmoBTS I am getting some
missing packages. It is asking for libosmotrau which I understand why it
wants it so I have installed libosmoabis but couldnot find libosmotrau as a
separate package.. Can you please share me the libosmotrau package.

Thanks
Anindya

On Wed, Oct 11, 2017 at 1:06 PM, Harald Welte <laforge at gnumonks.org> wrote:

> On Wed, Oct 11, 2017 at 12:58:35PM +0530, Anindya Sankar Roy wrote:
> > Hello,
> >
> >  Yes I did start osmo-stp but can you please tell me how to configure the
> > osmo-stp port ? I am just thinking that maybe that is the reason why its
> > not starting.
> >   By the way can you please share your cfg file, I would want to take a
> > look at it and see if I am missing anything.
>
> all osmocom projects come with "reasonable" example configuration files,
> typically in the "doc/examples" folder.  Starting osmo-bsc, osmo-msc and
> osmo-stp
> with those example configs on the same machine should render a setup in
> which BSC and MCS connect to the STP and can exchange BSSAP messages
> between
> them.
>
> If you experience problems, please provide _proper_ reports, including your
> config files, the log/stderr output as well as a pcap protocol trace of
> the relevan
> communication (M3UA on loopback device in case of running all programs on
> one machine).
>
> https://media.ccc.de/v/osmocon17-4008-reporting_and_
> investigating_issues_in_osmocom
> also provides some help on what kind of information is required.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171017/dd4d7db9/attachment.htm>

From anindya.s at toshniwalcontrols.com  Tue Oct 17 06:49:22 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 17 Oct 2017 12:19:22 +0530
Subject: Integrating openBSC with 3rd party MSC
In-Reply-To: <CAAj2SE0zKvnMHnP+qM7kdvoKxniaTQ-Jybj0LLhojGKYNH5tcw@mail.gmail.com>
References: <CAAj2SE2kE23aXLdPEf4-KCYrYy-rd79QGnGFrVfAg8+ELbTcaQ@mail.gmail.com>
 <20171003230557.GE3156@my.box>
 <CAAj2SE0mcMzYLyqM1vNhgoE5Ef9jpjw6MJCR+cJLjNsggC_xPw@mail.gmail.com>
 <20171006142240.GB29730@my.box>
 <CAAj2SE1_hz+39_w7vP6bHCSFbuyw1AX1JezxXLXDxBJ1spHakg@mail.gmail.com>
 <20171008185530.GA15349@my.box>
 <8514FDE8-A161-417E-AF23-5A55E9087014@freyther.de>
 <20171009133700.GA31761@my.box> <20171010135232.GF2043@my.box>
 <CAAj2SE1P1pHvMu1ZY6WLgfEstnv_QE9QQnwQx1OHHJk-A6xDJg@mail.gmail.com>
 <20171011073632.xmx7npdw7fcc2m7d@nataraja>
 <CAAj2SE0zKvnMHnP+qM7kdvoKxniaTQ-Jybj0LLhojGKYNH5tcw@mail.gmail.com>
Message-ID: <CAAj2SE2zgFagyP1ThHLZNfMLgFx4ZzZRN3XMjFpQ6SqQeht7xw@mail.gmail.com>

Hello,

 Removing all the libosmoabis and reinstalling solved me this issue.

Thanks
Anindya

On Tue, Oct 17, 2017 at 12:06 PM, Anindya Sankar Roy <
anindya.s at toshniwalcontrols.com> wrote:

> Hello,
>
>  I figured out my issue with the BSC to MSC link and have solved it, it
> was actually the OPC DPC that caused all of it.
>              Now I am working on Blade RF (SDR) to build the bsc ... I
> have installed osmoSDR and now while I am building osmoBTS I am getting
> some missing packages. It is asking for libosmotrau which I understand why
> it wants it so I have installed libosmoabis but couldnot find libosmotrau
> as a separate package.. Can you please share me the libosmotrau package.
>
> Thanks
> Anindya
>
> On Wed, Oct 11, 2017 at 1:06 PM, Harald Welte <laforge at gnumonks.org>
> wrote:
>
>> On Wed, Oct 11, 2017 at 12:58:35PM +0530, Anindya Sankar Roy wrote:
>> > Hello,
>> >
>> >  Yes I did start osmo-stp but can you please tell me how to configure
>> the
>> > osmo-stp port ? I am just thinking that maybe that is the reason why its
>> > not starting.
>> >   By the way can you please share your cfg file, I would want to take a
>> > look at it and see if I am missing anything.
>>
>> all osmocom projects come with "reasonable" example configuration files,
>> typically in the "doc/examples" folder.  Starting osmo-bsc, osmo-msc and
>> osmo-stp
>> with those example configs on the same machine should render a setup in
>> which BSC and MCS connect to the STP and can exchange BSSAP messages
>> between
>> them.
>>
>> If you experience problems, please provide _proper_ reports, including
>> your
>> config files, the log/stderr output as well as a pcap protocol trace of
>> the relevan
>> communication (M3UA on loopback device in case of running all programs on
>> one machine).
>>
>> https://media.ccc.de/v/osmocon17-4008-reporting_and_investig
>> ating_issues_in_osmocom
>> also provides some help on what kind of information is required.
>>
>> --
>> - Harald Welte <laforge at gnumonks.org>
>> http://laforge.gnumonks.org/
>> ============================================================
>> ================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                   (ETSI EN 300 175-7 Ch.
>> A6)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171017/e4bf690c/attachment.htm>

From pablo at gnumonks.org  Tue Oct 17 09:28:34 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Tue, 17 Oct 2017 11:28:34 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171015161844.b4pzuzpadgrasfc4@nataraja>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <f092e2ad-d5a1-2383-46f3-35f129ae6e1c@rhizomatica.org>
 <20171015161844.b4pzuzpadgrasfc4@nataraja>
Message-ID: <20171017092834.GA6429@salvia>

Hi Harald,

On Sun, Oct 15, 2017 at 06:18:44PM +0200, Harald Welte wrote:
[...]
> On Sun, Oct 15, 2017 at 10:48:49AM -0500, Keith wrote:
> > Yes, certainly for OsmoDevCon, Seville would mean travel and
> > expense for most.
> > ?But how about the OsmoCon (assuming the decision was not to
> > have them back-to-back)?
> 
> Possible, but I'm not sure if Pablo was volunteering for a significantly
> larger event: OsmoCon was 60 people this year, so I would expect it to
> be at least that same size next year.

We can do this here too. I can find someone here - I promise it won't
be me - to volunteer to make cost estimations that we can deliver to
you asap, so you get an idea on whether this will be more expensive or
cheaper. Even if this is not organized this time, it can be useful in
the future to start moving the conference around Europe.

If flight costs are important, we would need to make a few questions
though, there are things like rough flight cost estimations that we
would like to make, so statistics on city/country of origin of people
that will attend may be useful.

No need to make it this time if it's too tight, we can very much
likely offer this later on.

> > I imagine that would mean a LOT more logistics work there,
> > maybe too much, like bringing CCC VOC for example.
> 
> Indeed.

Video recording should not be a problem here, if there's anything else
to take into account, let me know!

Thanks.


From nhofmeyr at sysmocom.de  Tue Oct 17 10:31:50 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 17 Oct 2017 12:31:50 +0200
Subject: Planning for OsmoCon + OsmoDevCon
In-Reply-To: <20171017092834.GA6429@salvia>
References: <20171014060140.khxczgit4pe2icuq@nataraja>
 <f092e2ad-d5a1-2383-46f3-35f129ae6e1c@rhizomatica.org>
 <20171015161844.b4pzuzpadgrasfc4@nataraja>
 <20171017092834.GA6429@salvia>
Message-ID: <20171017103150.GA6235@ass40.sysmocom.de>

On Tue, Oct 17, 2017 at 11:28:34AM +0200, Pablo Neira Ayuso wrote:
> Even if this is not organized this time, it can be useful in
> the future to start moving the conference around Europe.

From my own selfish viewpoint I so far really enjoy that everyone else is
travelling to my home town for Osmo*Con, and it kind of matches the CCC
related origins of Osmocom ... no real strong point against it I guess ;)

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171017/865bd469/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct 17 11:10:06 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 17 Oct 2017 13:10:06 +0200
Subject: OSMO-BTS-TRX maxdly and maxdlynb Configuration Save issue
In-Reply-To: <BAD9FD7D-8B81-49C9-A5C2-C113C2DD3445@entropysolution.com>
References: <BAD9FD7D-8B81-49C9-A5C2-C113C2DD3445@entropysolution.com>
Message-ID: <20171017111006.GB6235@ass40.sysmocom.de>

> But after saving the configuration and restarting the osmo-bts-trx instance, it give an unable to parse error.

Thanks for reporting this!

A fix of this and other similar issues I found in the osmo-bts-trx vty are
at https://gerrit.osmocom.org/4314

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171017/6e9c8c6c/attachment.bin>

From robert.steve07 at gmail.com  Wed Oct 18 08:30:04 2017
From: robert.steve07 at gmail.com (robert)
Date: Wed, 18 Oct 2017 11:30:04 +0300
Subject: OSMO UMTS
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
Message-ID: <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>

Hi,

Can a UMTS network be implemented using what is already available from OSMO projects ?



From laforge at gnumonks.org  Wed Oct 18 08:57:53 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 18 Oct 2017 10:57:53 +0200
Subject: OSMO UMTS
In-Reply-To: <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
 <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
Message-ID: <20171018085752.lix5ke3uccjph5aj@nataraja>

On Wed, Oct 18, 2017 at 11:30:04AM +0300, robert wrote:
> Can a UMTS network be implemented using what is already available from OSMO projects ?

Yes, see http://osmocom.org/news/59 (about one year ago) and http://osmocom.org/news/67

However, you need a [proprietary] femtocell, small cell or classic
NodeB+RNC which can provide either an Iuh or an Iu interface over IP to
the Osmocom stack.  So it's basically at the stage where we were with
GSM in 2008-2010 and you needed a proprietary BTS and we had everything
from the BSC upwards in Osmocom.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From robert.steve07 at gmail.com  Wed Oct 18 09:22:44 2017
From: robert.steve07 at gmail.com (robert)
Date: Wed, 18 Oct 2017 12:22:44 +0300
Subject: OSMO UMTS
In-Reply-To: <20171018085752.lix5ke3uccjph5aj@nataraja>
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
 <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
 <20171018085752.lix5ke3uccjph5aj@nataraja>
Message-ID: <35B17453-957C-4EC5-B18B-57BD9D87A1AB@gmail.com>

Hi,

I don?t know much about femtocells, where can I get one and does it connect to any 3G operator ?



On Oct 18, 2017, at 11:57 AM, Harald Welte <laforge at gnumonks.org> wrote:

> On Wed, Oct 18, 2017 at 11:30:04AM +0300, robert wrote:
>> Can a UMTS network be implemented using what is already available from OSMO projects ?
> 
> Yes, see http://osmocom.org/news/59 (about one year ago) and http://osmocom.org/news/67
> 
> However, you need a [proprietary] femtocell, small cell or classic
> NodeB+RNC which can provide either an Iuh or an Iu interface over IP to
> the Osmocom stack.  So it's basically at the stage where we were with
> GSM in 2008-2010 and you needed a proprietary BTS and we had everything
> from the BSC upwards in Osmocom.
> 
> Regards,
> 	Harald
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Wed Oct 18 10:12:33 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 18 Oct 2017 12:12:33 +0200
Subject: OSMO UMTS
In-Reply-To: <35B17453-957C-4EC5-B18B-57BD9D87A1AB@gmail.com>
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
 <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
 <20171018085752.lix5ke3uccjph5aj@nataraja>
 <35B17453-957C-4EC5-B18B-57BD9D87A1AB@gmail.com>
Message-ID: <20171018101233.cheilkyz7be4clla@nataraja>

Hi Robert,

On Wed, Oct 18, 2017 at 12:22:44PM +0300, robert wrote:
> I don?t know much about femtocells, where can I get one

sysmocom is selling femtocells both individually as well as part of the
"sysmoNITB 3G5 Starter Kit".

Please note that there is nothing sysmocom-specific in the Osmo-Iuh
code, you should be able to use any device that exposes its Iuh or
IuCS/IuPS over IP.

> does it connect to any 3G operator ?

No, a femtocell sold to an end-user/consumer will typically only connect
to the one operator to which it was provisioned to connect.  The
femtocell and small-cell devices shipped by sysmocom are special in that
regard, as they are sold to you as the operator of your network.  This
means that you can configure where it shall connect, and what kind of
authentication/credentials to use (if any).

Still, you will only be able to connect those femtocells to a core
network that you control (Such as one based on an installation of the
Osmocom components), as you will not have credentials to authenticate to
an operator that is not under your control (such as regular commercial
cellular operators like Vodafone or T-Mobile).

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From robert.steve07 at gmail.com  Wed Oct 18 10:45:56 2017
From: robert.steve07 at gmail.com (robert)
Date: Wed, 18 Oct 2017 13:45:56 +0300
Subject: OSMO UMTS
In-Reply-To: <20171018101233.cheilkyz7be4clla@nataraja>
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
 <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
 <20171018085752.lix5ke3uccjph5aj@nataraja>
 <35B17453-957C-4EC5-B18B-57BD9D87A1AB@gmail.com>
 <20171018101233.cheilkyz7be4clla@nataraja>
Message-ID: <DB9BCF51-C31D-4332-9DED-C7282CC584A0@gmail.com>


On Oct 18, 2017, at 1:12 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Robert,
> 
> On Wed, Oct 18, 2017 at 12:22:44PM +0300, robert wrote:
>> I don?t know much about femtocells, where can I get one
> 
> sysmocom is selling femtocells both individually as well as part of the
> "sysmoNITB 3G5 Starter Kit".
> 
> Please note that there is nothing sysmocom-specific in the Osmo-Iuh
> code, you should be able to use any device that exposes its Iuh or
> IuCS/IuPS over IP.
> 
>> does it connect to any 3G operator ?
> 
> No, a femtocell sold to an end-user/consumer will typically only connect
> to the one operator to which it was provisioned to connect.  The
> femtocell and small-cell devices shipped by sysmocom are special in that
> regard, as they are sold to you as the operator of your network.  This
> means that you can configure where it shall connect, and what kind of
> authentication/credentials to use (if any).
> 
Sounds great ! So I can connect it to any operator provided that I have the required credentials.

> Still, you will only be able to connect those femtocells to a core
> network that you control (Such as one based on an installation of the
> Osmocom components), as you will not have credentials to authenticate to
> an operator that is not under your control (such as regular commercial
> cellular operators like Vodafone or T-Mobile).
> 
Does this mean that if I have a femtocell that is connected to an operator that I control, then I must manually tell my phone to connect to the femtocell ? How will the phone be able to differentiate between the original operator and the femtocell if both share the same signature ? 

> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Wed Oct 18 12:23:55 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 18 Oct 2017 14:23:55 +0200
Subject: OSMO UMTS
In-Reply-To: <DB9BCF51-C31D-4332-9DED-C7282CC584A0@gmail.com>
References: <E0B47CBD-EE39-4AB1-9C6E-208891F0F833@gmail.com>
 <A3292736-6E3F-4445-A919-319F64824C04@gmail.com>
 <20171018085752.lix5ke3uccjph5aj@nataraja>
 <35B17453-957C-4EC5-B18B-57BD9D87A1AB@gmail.com>
 <20171018101233.cheilkyz7be4clla@nataraja>
 <DB9BCF51-C31D-4332-9DED-C7282CC584A0@gmail.com>
Message-ID: <20171018122355.u6xflagels33apmy@nataraja>

Hi Robert,

On Wed, Oct 18, 2017 at 01:45:56PM +0300, robert wrote:
> Does this mean that if I have a femtocell that is connected to an
> operator that I control, then I must manually tell my phone to connect
> to the femtocell ? 

Not neccessarily.  Depends on your detailed configuration.

> How will the phone be able to differentiate between the original
> operator and the femtocell if both share the same signature ? 

Normally you would insert the SIM Card of your own operator when running
phones on your own network.  Just like normal operators out there,
nothing special.  Normal cell/network selection procedures of phones
apply.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From msuraev at sysmocom.de  Wed Oct 18 16:50:17 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 18 Oct 2017 18:50:17 +0200
Subject: .deb updates in Debian/Ubuntu repos
Message-ID: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>

Hi.

For quite some time Osmocom packages are available in Debian [1] and Ubuntu [2]
repositories. That's a really nice thing although there're only minor distro-specific
updates between different releases so far.

In addition to usual "fix old bugs, add new features (and bugs :)" progress, there're
bigger changes happening in Osmocom [3] projects.

Most notably: we now have multiple repositories for BSC/MSC/SGSN instead of single
OpenBSC repo. The process is not finished yet (doc/manuals update is still under way
for example) but I think it's already a good time to discuss how can we bring those
changes into Debian/Ubuntu repositories. We already have nightly builds for all
packages from new repositories [4] as well as old ones [5].

The basic question is - what shall we do to get the packages built from new
repositories into Debian/Ubuntu?

Is there something we (upstream) can do, to facilitate the process?

Are there some notable .deb-specific patches you'd like to see merged?

Should I have used some other channel to communicate instead of emails I've fetched
from changelogs?

[1]
https://packages.debian.org/search?keywords=osmocom&searchon=names&suite=stable&section=all

[2]
https://packages.ubuntu.com/search?suite=all&section=all&arch=amd64&keywords=osmocom&searchon=names

[3] https://osmocom.org/issues/2257

[4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:nightly

[5] https://build.opensuse.org/project/monitor/network:osmocom:nightly

-- 
Max Suraev <msuraev at 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 






From debian at alteholz.de  Wed Oct 18 21:04:09 2017
From: debian at alteholz.de (Thorsten Alteholz)
Date: Wed, 18 Oct 2017 23:04:09 +0200 (CEST)
Subject: .deb updates in Debian/Ubuntu repos
In-Reply-To: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
Message-ID: <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>

Hi Max,

On Wed, 18 Oct 2017, Max wrote:
> The basic question is - what shall we do to get the packages built from new
> repositories into Debian/Ubuntu?

I am already looking at those new repositories and there will be packages 
soon ...

> Is there something we (upstream) can do, to facilitate the process?

As maintaining the copyright information in debian/copyright is the most 
boring task of a maintainer, maybe you can take over this? :-)

> Are there some notable .deb-specific patches you'd like to see merged?

No, I didn't encounter any strange stuff you do yet, so I don't expect any 
patches in this regard.
Thus, some time ago I already started to submit patches to some other 
repositories for stuff that lintian complains about ...

> Should I have used some other channel to communicate instead of emails I've fetched
> from changelogs?

No, from my point of view this is totally fine.

   Thorsten



From gsm.sim.conn at gmail.com  Thu Oct 19 12:15:16 2017
From: gsm.sim.conn at gmail.com (gsm sim)
Date: Thu, 19 Oct 2017 14:15:16 +0200
Subject: osmo-bsc and msc connection
Message-ID: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>

Hello everyone,

we are struggling to set up an 2G network using single bsc and msc
components rather than osmo-nitb.
We successfully managed to run an 2G-Network with osmo-nitb using an
usrp-n210 as trx.

Now how is the BSC supposed to connect to the MSC? In an older build of the
osmo-bsc and like described in the osmo-msc user manual I was able to setup
an cs7 instance using the m3ua via osmo-stp to the msc. But as I'm using
the nighlty-packages now there is no longer a way to configure cs7
instances in the BSC and since we are completely new to this project we
aren't up to date with all the recent changes. Apologizes for that.

We're also struggling to build the osmo-bsc sources. It quits with
"bsc_vty.c:313:5: error: implicit declaration of function ?OSMO_SEC2DAY?".
So I guess there is a package missing but I couldn't find out which one it
is.

TIA

Best regards,

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171019/8e73d7bd/attachment.htm>

From msuraev at sysmocom.de  Thu Oct 19 12:19:48 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 19 Oct 2017 14:19:48 +0200
Subject: osmo-bsc and msc connection
In-Reply-To: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
References: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
Message-ID: <a2e216d7-d7af-3b84-89f3-242b9639cb4c@sysmocom.de>

On 19.10.2017 14:15, gsm sim wrote:
> We're also struggling to build the osmo-bsc sources. It quits with "bsc_vty.c:313:5:
> error: implicit declaration of function ?OSMO_SEC2DAY?". So I guess there is a
> package missing but I couldn't find out which one it is.

That means the version of libosmocore you're using is too old. In general, rule of
thumb is: if you build latest master of osmo* than you also have to install the
latest master of all of its libosmo* dependencies.

-- 
Max Suraev <msuraev at 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






From nhofmeyr at sysmocom.de  Thu Oct 19 15:11:04 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 19 Oct 2017 17:11:04 +0200
Subject: osmo-bsc and msc connection
In-Reply-To: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
References: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
Message-ID: <20171019151104.GB1849@ass40.sysmocom.de>

On Thu, Oct 19, 2017 at 02:15:16PM +0200, gsm sim wrote:
> Now how is the BSC supposed to connect to the MSC?

osmo-bsc --> osmo-stp <-- osmo-msc

The cs7 instance setup you mention should work.

BTW, I have the task of writing a migration guide from OsmoNITB to
separate OsmoBSC+OsmoMSC that should cover these topics, which I'm
planning to start today. It should be in the osmocom.org wiki soon.

> I'm using the nighlty-packages 

Note that so far there are separate repositories, one containing the old
osmo-bsc binary that only speaks SCCPlite, and a separate one with the new
packages that speak SCCP/M3UA.

The subtle difference at the moment is that the new SCCP/M3UA version of
osmo-bsc is called 'osmo-bsc_*.deb' and is in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly

While the old osmo-bsc version that can only do SCCPlite and has no M3UA
support is called 'osmocom-bsc_*.deb' ('osmocom' vs. 'osmo') and is in
https://build.opensuse.org/project/show/network:osmocom:nightly

(We are working on it to join the "split" ones with the standard "nightly"
feed)

See also
https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds

In our OpenEmbedded builds, we have already renamed the old osmo-bsc to
'osmo-bsc-sccplite', it might be a good idea to do the same for debian
packaging.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171019/48033884/attachment.bin>

From gsm.sim.conn at gmail.com  Fri Oct 20 07:46:56 2017
From: gsm.sim.conn at gmail.com (gsm sim)
Date: Fri, 20 Oct 2017 09:46:56 +0200
Subject: osmo-bsc and msc connection
In-Reply-To: <20171019151104.GB1849@ass40.sysmocom.de>
References: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
 <20171019151104.GB1849@ass40.sysmocom.de>
Message-ID: <CAP+5MexoxVoWN0pv0qZMGkhWX==RPiDr+qryEnsZAvm+yfaCiQ@mail.gmail.com>

Hello guys,

thanks a lot for your answers. So it looks like our failure was to use a
mix of the wrong nightly builds and builds from source. I'm in the process
of implementing the right repos now. Good to see that we were on the right
way with our bsc -> stp <- msc setup and can narrow down our confusion.

On Thu, Oct 19, 2017 at 5:11 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> BTW, I have the task of writing a migration guide from OsmoNITB to
> separate OsmoBSC+OsmoMSC that should cover these topics, which I'm
> planning to start today. It should be in the osmocom.org wiki soon

Looking forward to your guide helping with some open questions.

Best regards and have a nice weekend,

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171020/6861263a/attachment.htm>

From laforge at gnumonks.org  Fri Oct 20 08:02:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 20 Oct 2017 10:02:04 +0200
Subject: osmo-bsc and msc connection
In-Reply-To: <CAP+5MexoxVoWN0pv0qZMGkhWX==RPiDr+qryEnsZAvm+yfaCiQ@mail.gmail.com>
References: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
 <20171019151104.GB1849@ass40.sysmocom.de>
 <CAP+5MexoxVoWN0pv0qZMGkhWX==RPiDr+qryEnsZAvm+yfaCiQ@mail.gmail.com>
Message-ID: <20171020080204.ltbmv4q7xn3h6ckf@nataraja>

On Fri, Oct 20, 2017 at 09:46:56AM +0200, gsm sim wrote:
> Hello guys,
> 
> thanks a lot for your answers. So it looks like our failure was to use a
> mix of the wrong nightly builds and builds from source. 

I wonder why you were building something from source at all.  Everything is packaged
as nightly builds, and unless you are making some changes to the code (which we
are very happy to receive as contribution to the project!) there shouldn't be
a need to build from source.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From msuraev at sysmocom.de  Fri Oct 20 09:16:35 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 20 Oct 2017 11:16:35 +0200
Subject: .deb updates in Debian/Ubuntu repos
In-Reply-To: <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
 <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
Message-ID: <879a2f20-b8f1-1e3c-1483-07ce0e140d7d@sysmocom.de>

Hi!

On 18.10.2017 23:04, Thorsten Alteholz wrote:
> I am already looking at those new repositories and there will be packages soon ...

Glad to hear that.

> As maintaining the copyright information in debian/copyright is the most boring
> task of a maintainer, maybe you can take over this? :-)

I've submitted few patches to it recently but that's just some stuff I've spotted by
accident when looking at lintian output. Are there some tools/docs about it? I mean
what's the actual maintenance procedure?

I'm not promising I'll keep it 100% updated all the time :-) but at least we can
document this in the wiki and maybe try to plug it into release automation scripts.

-- 
Max Suraev <msuraev at 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 






From sudhanthiradasan.r at hcl.com  Fri Oct 20 09:43:40 2017
From: sudhanthiradasan.r at hcl.com (Sudhanthiradasan R)
Date: Fri, 20 Oct 2017 09:43:40 +0000
Subject: Location Update Error
Message-ID: <HKNPR0401MB18418EEAB23A498529434D1194430@HKNPR0401MB1841.apcprd04.prod.outlook.com>

Hi,

I have even tried authorizing imsi via sql. I could able to authorize by following https://osmocom.org/projects/osmonitb/wiki/OsmoNITB   and it lists the extension number, exactly what I have assigned.
But the error still persists.


Issues listed below is similar to what I'm facing but is there any solution for this?
http://lists.osmocom.org/pipermail/openbsc/2012-February/004695.html
https://osmocom.org/issues/1648#note-19


Thanks,
Sudhanthiradasan R

From: Sudhanthiradasan R
Sent: Monday, October 16, 2017 6:28 PM
To: openbsc at lists.osmocom.org
Subject: Location Update Error

Hello,

I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM"

<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5
<0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS.
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION
<0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE
<0002> gsm_04_08.c:596 Location Updating Request procedure timedout.
<0002> gsm_04_08.c:474 Subscriber 901550000001016:
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS.


Anyone had the same issue earlier? Is there any solution for this error?


Thanks,
Sudhanthiradasan R


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171020/9585a581/attachment.htm>

From gsm.sim.conn at gmail.com  Fri Oct 20 09:58:23 2017
From: gsm.sim.conn at gmail.com (gsm sim)
Date: Fri, 20 Oct 2017 11:58:23 +0200
Subject: osmo-bsc and msc connection
In-Reply-To: <20171020080204.ltbmv4q7xn3h6ckf@nataraja>
References: <CAP+5MezXQ=fqgtp7e1T38a0yO3rAOKS7=61jkNhgp=25usEvxg@mail.gmail.com>
 <20171019151104.GB1849@ass40.sysmocom.de>
 <CAP+5MexoxVoWN0pv0qZMGkhWX==RPiDr+qryEnsZAvm+yfaCiQ@mail.gmail.com>
 <20171020080204.ltbmv4q7xn3h6ckf@nataraja>
Message-ID: <CAP+5Mez++mmTzB6fE219z4_=fVTkPBskiDBLNRFCGYLu6rTZtA@mail.gmail.com>

On Fri, Oct 20, 2017 at 10:02 AM, Harald Welte <laforge at gnumonks.org> wrote:

> > I wonder why you were building something from source at all.
>

Yeah now with the recent experience I got from the mailing list I'm
wondering too.
So we weren't aware of the nitb-split nightly builds at all and due to that
we had an inconsistent mix of builds...

In terms of communication between bts - bsc - stp - msc - mgw everything is
fine now. There are other problems now but I think this is related to false
configuration.

Regards,

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171020/d34ed014/attachment.htm>

From msuraev at sysmocom.de  Fri Oct 20 11:23:27 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 20 Oct 2017 13:23:27 +0200
Subject: libversion update question
Message-ID: <2496cf18-26c5-a109-4080-b28832e661b0@sysmocom.de>

Hi.

When we're making new library release we got to make sure that the API/ABI versions
are properly updated by correctly setting *_LIBVERSION which has 3 components:
current[:revision[:age]].

That's documented in
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

The rules are as follows:

1. If the library source code has changed at all since the last update, r++;
2. If any interfaces have been added, removed, or changed since the last update, c++,
r=0;
3. If any interfaces have been added since the last public release, a++;
4. If any interfaces have been removed or changed since the last public release, a=0.

What's not clear to me is how those rules should be used. Do we apply them sequentially?

For example, I've added function lol_what() to public API of my library with previous
LIBVERSION=3:2:1 and would like to compute new LIBVERSION properly.

According to rule #1 I've got to update revision: 3:3:1

According to rule #2 I've got to update current and reset revision: 4:0:1

The rules are conflicting so let's assume latest rule wins and apply further rules:

According to rule #3 I've got to increase age: 4:0:2

So far so good but do correct me if I'm misunderstanding it.

Now LIBVERSION=4:0:2 is released, I've removed lol_what() and added foobar()
functions. Let's bump the LIBVERSION:

#1: 4:1:2

#2: 5:0:2

#3: 5:0:3

#4: 5:0:0

Am I interpreting this right? We only increase revision if no interfaces have been
added, removed, or changed since the last update? This means that "current" and
"revision" increments are mutually exclusive.

-- 
Max Suraev <msuraev at 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 






From nhofmeyr at sysmocom.de  Sat Oct 21 14:24:43 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 21 Oct 2017 16:24:43 +0200
Subject: libversion update question
In-Reply-To: <2496cf18-26c5-a109-4080-b28832e661b0@sysmocom.de>
References: <2496cf18-26c5-a109-4080-b28832e661b0@sysmocom.de>
Message-ID: <20171021142443.GC14602@my.box>

On Fri, Oct 20, 2017 at 01:23:27PM +0200, Max wrote:
> The rules are as follows:
>

c:r:a

> 1. If the library source code has changed at all since the last update, r++;
> 2. If any interfaces have been added, removed, or changed since the last update, c++,
> r=0;
> 3. If any interfaces have been added since the last public release, a++;
> 4. If any interfaces have been removed or changed since the last public release, a=0.
> 
> What's not clear to me is how those rules should be used. Do we apply them sequentially?

Yes, apply all of them in sequence.

> For example, I've added function lol_what() to public API of my library with previous
> LIBVERSION=3:2:1 and would like to compute new LIBVERSION properly.
> 
> According to rule #1 I've got to update revision: 3:3:1
> 
> According to rule #2 I've got to update current and reset revision: 4:0:1
> 
> The rules are conflicting so let's assume latest rule wins and apply further rules:

Not conflict, they build up on each other.

> According to rule #3 I've got to increase age: 4:0:2

Correct, and #4 does not apply.

> Now LIBVERSION=4:0:2 is released, I've removed lol_what() and added foobar()
> functions. Let's bump the LIBVERSION:
> 
> #1: 4:1:2
> 
> #2: 5:0:2
> 
> #3: 5:0:3
> 
> #4: 5:0:0
> 
> Am I interpreting this right?

Yes.

> We only increase revision if no interfaces have been
> added, removed, or changed since the last update? This means that "current" and
> "revision" increments are mutually exclusive.

Indeed, can be put this way. 'revision' is increased to indicate that some
internal behavior has changed, like bug fixes or optimizations, log output,
stuff like that. As soon as any API/ABI interface has changed, we need to
update 'current'. So it's like c:r make up a sort of semantic versioning, kind
of like 'major:patch'.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171021/3002a5f4/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Oct 22 19:02:25 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 22 Oct 2017 21:02:25 +0200
Subject: Build failure of network:osmocom:nightly/libosmocore in
 xUbuntu_16.04/i586
In-Reply-To: <59eba623b9c96_40867bef80789698@build.opensuse.org>
References: <build-dac82272382619b999d5600524fe387b@build.opensuse.org>
 <59eba623b9c96_40867bef80789698@build.opensuse.org>
Message-ID: <20171022190225.GA19965@my.box>

On Sat, Oct 21, 2017 at 07:55:00PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmocore/xUbuntu_16.04/i586
> 
> Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_16.04/i586

The failure is

[  235s] +/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 32555 Illegal instruction     $abs_top_builddir/tests/conv/conv_gsm0503_test

Seems our cpu feature selection isn't working on that particular build host.
Should we investigate or just hope to hit another build host next time?

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171022/aa76c824/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Oct 22 19:34:07 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 22 Oct 2017 21:34:07 +0200
Subject: [MERGED] libosmocore[master]: Cleanup jenkins build scripts
References: <gerrit.1499266771623.I24e500e132f5c8e8133d35548cb7b4e4552331d0@gerrit.osmocom.org>
Message-ID: <20171022193347.GA20477@my.box>

This patch was merged, but I frankly don't like what it does.

Building in a separate dir is fine, but it does so with a bunch of changes
along that introduce indenting errors and potentially destroy the scripts'
certainty of building cleanly every time.

Please still reply to my comments at
https://gerrit.osmocom.org/#/c/3132/

...maybe actually here on the ML instead of on gerrit?

Thanks!

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171022/7a1ee51e/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Oct 22 21:25:00 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 22 Oct 2017 23:25:00 +0200
Subject: some current patches blocking others
Message-ID: <20171022212500.GB20477@my.box>

Would like to mention, since it's hard to see the sequence of patches in
gerrit. I have a series of osmo-hlr patches ready for commit, but others
preceding them still need review:

https://gerrit.osmocom.org/#/c/4305/

https://gerrit.osmocom.org/#/c/4273/
https://gerrit.osmocom.org/#/c/4275/

...whenever you get a chance is fine, thx!

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171022/bdad60d2/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 23 08:35:08 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 23 Oct 2017 10:35:08 +0200
Subject: Build failure of network:osmocom:nightly/libosmocore in
 xUbuntu_16.04/i586
In-Reply-To: <20171022190225.GA19965@my.box>
References: <build-dac82272382619b999d5600524fe387b@build.opensuse.org>
 <59eba623b9c96_40867bef80789698@build.opensuse.org>
 <20171022190225.GA19965@my.box>
Message-ID: <082e51e6-ad99-9bcd-6197-e6a4e55ba5fe@sysmocom.de>

It's already investigated: https://osmocom.org/issues/2386
Feel free to update the ticket further.

On 22.10.2017 21:02, Neels Hofmeyr wrote:
>
> Seems our cpu feature selection isn't working on that particular build host.
> Should we investigate or just hope to hit another build host next time?
>

-- 
Max Suraev <msuraev at 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 






From laforge at gnumonks.org  Mon Oct 23 09:57:42 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Oct 2017 11:57:42 +0200
Subject: [MERGED] libosmocore[master]: Cleanup jenkins build scripts
In-Reply-To: <20171022193347.GA20477@my.box>
References: <gerrit.1499266771623.I24e500e132f5c8e8133d35548cb7b4e4552331d0@gerrit.osmocom.org>
 <20171022193347.GA20477@my.box>
Message-ID: <20171023095742.vhowkh6ibfy3wrpe@nataraja>

Hi Neels,

On Sun, Oct 22, 2017 at 09:34:07PM +0200, Neels Hofmeyr wrote:
> This patch was merged, but I frankly don't like what it does.
> 
> Building in a separate dir is fine, but it does so with a bunch of changes
> along that introduce indenting errors and potentially destroy the scripts'
> certainty of building cleanly every time.

I though there was two subsequent runs of "autoreconf -fi", one for building in-source
and one for building out-of-source, and the rm-rf is the cause of it.  Maybe I have
misunderstood what the original code was intending to do.  In any case, an out-of-source
build "autoreconf -fi" will not have different results from one for in-source,
which is why I thought the patch is a good idea.

A common scripts for three lines seems rather odd to me, too - but then,
I don't really care all too much.

I'm not opposed to reverting it. Your call.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Oct 23 10:43:52 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Oct 2017 12:43:52 +0200
Subject: layer23/mobile: VTY is broken
In-Reply-To: <20171023015440.GC20477@my.box>
References: <CAPEnp=afYaGxVC_NN8CArU09oHhkzGXwZaWmGJ9eSV2BaMVChg@mail.gmail.com>
 <20171022191151.GC19965@my.box>
 <CAPEnp=YgDnzK5NRPO3di6xM1NKEGmMUdaqBeb6tN2FaA3UpzBw@mail.gmail.com>
 <20171023015440.GC20477@my.box>
Message-ID: <20171023104352.fwsnw36rkptwi5gl@nataraja>

Hi Neels,

On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
> Ah, damn. I checked all of the repositories I know to use the VTY, I didn't
> imagine that OsmocomBB also has a VTY. That's really my fault then.

I think in general we should not fall into that trap.  We have *no clue* at all
who might be using libosmo* for whatever purpose.  If we provide a libary with
a given API/ABI, then it's our responsibility to keep that ABI/API as stable as
possible.

I understand that it was hardly possible without fall-out in that particular
case, and for sure there are exceptions.

However, completely unrelated to this particular topic (and hence the Cc
to openbsc@) I'm not happy in general with the way how "carlessly" we
sometimes introduce breakage.  We have to be more disciplined in general
on this.  All of us.

BTW: The fact that this change has gone into master without being
noticed also means that possibly we're not modelling osmocom-bb as a
downstream user of libosmocore that needs to be rebuilt (and at least
checked if it starts up correctly?) whenever testing a libosmocore
change.  That's also something to investigate.  Maybe there's some way
we can test this without too much effort.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Mon Oct 23 14:24:57 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 23 Oct 2017 16:24:57 +0200
Subject: layer23/mobile: VTY is broken
In-Reply-To: <20171023104352.fwsnw36rkptwi5gl@nataraja>
References: <CAPEnp=afYaGxVC_NN8CArU09oHhkzGXwZaWmGJ9eSV2BaMVChg@mail.gmail.com>
 <20171022191151.GC19965@my.box>
 <CAPEnp=YgDnzK5NRPO3di6xM1NKEGmMUdaqBeb6tN2FaA3UpzBw@mail.gmail.com>
 <20171023015440.GC20477@my.box>
 <20171023104352.fwsnw36rkptwi5gl@nataraja>
Message-ID: <20171023142457.GB2123@my.box>

On Mon, Oct 23, 2017 at 12:43:52PM +0200, Harald Welte wrote:
> I think in general we should not fall into that trap.  We have *no clue* at all
> who might be using libosmo* for whatever purpose.  If we provide a libary with
> a given API/ABI, then it's our responsibility to keep that ABI/API as stable as
> possible.

True.

There are ways to fix this one: we can allow to register a given command a
second time, which then replaces the previously registered command. We can also
allow this only for the common node commands.

Should I implement this? Then upon new release, all potential VTY users out
there can still register their own common node commands to replace the default
ones and should not experience breakage.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171023/330e0088/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 23 15:17:07 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 23 Oct 2017 17:17:07 +0200
Subject: layer23/mobile: VTY is broken
In-Reply-To: <20171023142457.GB2123@my.box>
References: <CAPEnp=afYaGxVC_NN8CArU09oHhkzGXwZaWmGJ9eSV2BaMVChg@mail.gmail.com>
 <20171022191151.GC19965@my.box>
 <CAPEnp=YgDnzK5NRPO3di6xM1NKEGmMUdaqBeb6tN2FaA3UpzBw@mail.gmail.com>
 <20171023015440.GC20477@my.box> <20171023104352.fwsnw36rkptwi5gl@nataraja>
 <20171023142457.GB2123@my.box>
Message-ID: <1b9d887f-cd66-e13b-a2fd-1f65abfade37@sysmocom.de>

As a little side note: in future it's worth considering to make a release right
before pushing significant changes which might result in user-visible breakage. It's
easier to refer to version x.y.z than to git commit hash.

On 23.10.2017 16:24, Neels Hofmeyr wrote:
> Then upon new release, all potential VTY users out
> there can still register their own common node commands to replace the default
> ones and should not experience breakage.


-- 
Max Suraev <msuraev at 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 






From anindya.s at toshniwalcontrols.com  Tue Oct 24 11:50:19 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 24 Oct 2017 17:20:19 +0530
Subject: Problem running osmoBTS with BladeRF
Message-ID: <CAAj2SE0j6az901E041=nN91svRni6QDBBfsMdD3oRf9X-fdzVA@mail.gmail.com>

Hello all,

I am getting the following error and osmocom-bts-virtual just closes giving
following error.

bts.c:208 Shutting down BTS 0, Reason Abis close
<0006> bts_model.c:161 Unimplemented bts_model_trx_deact_rf
<0006> bts_model.c:55 Unimplemented bts_model_trx_close

Please help

Thanks
Anindya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171024/9d23199d/attachment.htm>

From msuraev at sysmocom.de  Tue Oct 24 12:19:54 2017
From: msuraev at sysmocom.de (Max)
Date: Tue, 24 Oct 2017 14:19:54 +0200
Subject: .deb updates in Debian/Ubuntu repos
In-Reply-To: <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
 <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
Message-ID: <a00841fd-e2de-b9f9-b20b-e6ae7a3778ae@sysmocom.de>

Hi.

There's another question related to .deb packaging which emerged recently: how do we
update libraries properly?

Let's take concrete example - libosmo-netif, current version is 0.0.7; libversion is
3:0:0

I'd like to release new version: 0.0.8, libversion is 4:0:1

What do I do with debian/?

The library package named libosmonetif3.install
According to https://wiki.debian.org/TransitionBestPractices it should be renamed to
libosmonetif4.install because we're changing "current" component of libversion.

We should also change debian/control to reflect this rename, but what about
"Conflicts:" in there?
I've tried reading
https://debian-handbook.info/browse/stable/sect.package-meta-information.html but
still not sure how it should be applied in case of shared libraries.

Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2?
Shall we use /Replaces instead? If so, for which version(s)?

Also, am I even reading this in the right place or there're some better docs
recommended for Debian library packaging?
/

-- 
Max Suraev <msuraev at 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 






From hwelte at sysmocom.de  Tue Oct 24 17:12:24 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Tue, 24 Oct 2017 19:12:24 +0200
Subject: libosmocore / rate_ctr / osmo_fsm / invalid identifiers
Message-ID: <20171024171224.wqsjgooad2z7czy7@nataraja>

Dear Osmocom comunity,

after my patches being in gerrit since October 3 without getting any
significant review comments, I decided to rebase+merge the code to
enforce correct "identifiers" for entnties like rate_ctr or osmo_fsm
which get registered to libosmocore and which are subsequently
automatically exported via CTRL.

A valid identifier is from now on known as any 7-bit ASCII string
excluding characters from the following set:
	:., {}[]()<>|~\\^`'\"?=;/+*&%$#!

This has caused some (not entirely unexpected) breakage in osmo-bts.git
and osmo-bsc.git and is the cause of a couple of "red" Jenkins builds
for those projects.  I've quickly followed-up with patches for those
two repositories to make sure other people/patches don't suffer from
fall-out.

What's important to note from now on and in the future:
* don't use any string identifiers that violate osmo_identifier_valid()
* check the return value of calls like osmo_fsm_register() as they may
  fail if your identifiers are incorrect
* use ':' as separator in rate_ctr_group or rate_ctr names.  Any existing
  '.' will be transparently converted to ':' for compatibility reasons.
* if you find other sub-systems in the libosmo* universe that use string
  identifiers for certain objects, let's try to introduce calls to
  osmo_identifier_valid() in all of their registration paths to ensure
  that we could later on add automatic export of such objects to CTRL
  or other interfaces without having to change the name at that point.
  Things that come to my mind are e.g.
  * SCCP global titles and AS/ASP names in libosmo-sigtran
  * SMPP ESME names in osmo-{msc,nitb}
  Patches welcome!

Regards,
	Harald
-- 
- Harald Welte <hwelte at 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


From nhofmeyr at sysmocom.de  Tue Oct 24 23:32:51 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Oct 2017 01:32:51 +0200
Subject: osmo-msc needs a fix of fsm names
Message-ID: <20171024233251.GA15893@my.box>

Talking about libosmocore changes that break builds ;)

By chance I noticed that since now osmo-gsm-tester tests fail for AoIP,
osmo-msc bailing with

fsm.c:150 Attempting to register FSM with illegal identifier 'FSM RESET'
fsm.c:216 Attempting to allocate FSM instance of type 'FSM RESET' with illegal identifier 'FSM RESET INST'

@pmaier, please fix osmo-msc's FSM name in a_reset.c ASAP. We can't test
OsmoMSC until you do. Thanks!

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171025/4da7f490/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct 24 23:36:15 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Oct 2017 01:36:15 +0200
Subject: osmo-msc needs a fix of fsm names
In-Reply-To: <20171024233251.GA15893@my.box>
References: <20171024233251.GA15893@my.box>
Message-ID: <20171024233615.GB15893@my.box>

On Wed, Oct 25, 2017 at 01:32:51AM +0200, Neels Hofmeyr wrote:
> fsm.c:150 Attempting to register FSM with illegal identifier 'FSM RESET'
> fsm.c:216 Attempting to allocate FSM instance of type 'FSM RESET' with illegal identifier 'FSM RESET INST'

forgot to point at https://osmocom.org/issues/2593

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171025/df20ac73/attachment.bin>

From mayuri.tendulkar at gmail.com  Wed Oct 25 06:35:15 2017
From: mayuri.tendulkar at gmail.com (Mayuri Tendulkar)
Date: Wed, 25 Oct 2017 12:05:15 +0530
Subject: Support in using slotmask
Message-ID: <CAKKcpk9koRzmwDJjOtRycCfpEE-MtUrm5+7y9DN+T7fP2SZbwg@mail.gmail.com>

Hi team

I want to test the data on timeslot basis, where I can activate alternate
timeslot oN B200.

How this is possible?

I tried to add parameters in bts-conf file with slotmask as 10101010. But I
don't see any change.

I also tried to change this value from 0xff to 0xaa in osmo-bts-trx code,
but I get error.

Can u please help?

Regards
Mayuri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171025/78daef7e/attachment.htm>

From pmaier at sysmocom.de  Wed Oct 25 08:32:11 2017
From: pmaier at sysmocom.de (Philipp Maier)
Date: Wed, 25 Oct 2017 10:32:11 +0200
Subject: osmo-msc needs a fix of fsm names
In-Reply-To: <20171024233251.GA15893@my.box>
References: <20171024233251.GA15893@my.box>
Message-ID: <72ce08aa-8531-148a-ca32-4fbf5922f585@sysmocom.de>

Hi Neels,

I have removed the whitespace now. See the following patches:

https://gerrit.osmocom.org/4408
https://gerrit.osmocom.org/4409

However, we have some code duplication here. Maybe we can move the reset 
into libosmo-sigtran or libosmocore?

regards.
Philipp

-- 
Philipp Maier <pmaier at 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


From msuraev at sysmocom.de  Wed Oct 25 08:50:30 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 25 Oct 2017 10:50:30 +0200
Subject: libosmocore / rate_ctr / osmo_fsm / invalid identifiers
In-Reply-To: <20171024171224.wqsjgooad2z7czy7@nataraja>
References: <20171024171224.wqsjgooad2z7czy7@nataraja>
Message-ID: <0ccd5e8b-8c8e-475a-c10b-4a3a61bab1c3@sysmocom.de>

There seems to be related build failure in osmo-sgsn which I've fixed in
https://gerrit.osmocom.org/#/c/4410/

I'm not sure how to fix failure in osmo-pcu or if it's related at all: tests fail with

ERROR: osmo_log_info == NULL! You must call log_init() before using logging!
Assert failed osmo_log_info logging.c:188

which was added several months ago. Any ideas?

-- 
Max Suraev <msuraev at 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 






From msuraev at sysmocom.de  Wed Oct 25 09:19:36 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 25 Oct 2017 11:19:36 +0200
Subject: libosmocore / rate_ctr / osmo_fsm / invalid identifiers
In-Reply-To: <20171024171224.wqsjgooad2z7czy7@nataraja>
References: <20171024171224.wqsjgooad2z7czy7@nataraja>
Message-ID: <dcf2fecc-3a27-a761-65f2-b69381e72a1a@sysmocom.de>

Ok, got it:

We run osmo_init_logging() in OsmoPCU tests but by that time rate_ctr_group_alloc()
is already called from BTS singleton constructor.
Calling osmo_init_logging()from there is not an option as we won't have logging
levels set properly - see

https://gerrit.osmocom.org/4411

for details.

Shall I move rate-ctr related code outside of singleton? Is there better solution?

-- 
Max Suraev <msuraev at 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 






From pmaier at sysmocom.de  Wed Oct 25 09:23:32 2017
From: pmaier at sysmocom.de (Philipp Maier)
Date: Wed, 25 Oct 2017 11:23:32 +0200
Subject: osmo-msc needs a fix of fsm names
In-Reply-To: <20171024233615.GB15893@my.box>
References: <20171024233251.GA15893@my.box> <20171024233615.GB15893@my.box>
Message-ID: <7861e25d-356a-2320-eec5-23c106aacfa2@sysmocom.de>

Hi Neels,

> forgot to point at https://osmocom.org/issues/2593

I see, I have now abandonned the msc patch again. It should be fine now. 
However, jenkins seems to have some problems. Probably unrelated to 
this, but i am not sure.

https://jenkins.osmocom.org/jenkins/job/osmo-bsc-gerrit/label=linux_amd64_debian8/152/consoleFull

regards,
Philipp

-- 
Philipp Maier <pmaier at 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


From laforge at gnumonks.org  Wed Oct 25 18:48:57 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 25 Oct 2017 20:48:57 +0200
Subject: Support in using slotmask
In-Reply-To: <CAKKcpk9koRzmwDJjOtRycCfpEE-MtUrm5+7y9DN+T7fP2SZbwg@mail.gmail.com>
References: <CAKKcpk9koRzmwDJjOtRycCfpEE-MtUrm5+7y9DN+T7fP2SZbwg@mail.gmail.com>
Message-ID: <20171025184857.yhn5f3cegluxsinl@nataraja>

Hi Mayuri,

from your e-mail it's unfortunately not clear what exactly you are trying
to achieve.  Please fill us in on the bigger picture so we can get an idea
of how to help.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From mayuri.tendulkar at gmail.com  Thu Oct 26 03:56:11 2017
From: mayuri.tendulkar at gmail.com (Mayuri Tendulkar)
Date: Thu, 26 Oct 2017 09:26:11 +0530
Subject: Support in using slotmask
In-Reply-To: <20171025184857.yhn5f3cegluxsinl@nataraja>
References: <CAKKcpk9koRzmwDJjOtRycCfpEE-MtUrm5+7y9DN+T7fP2SZbwg@mail.gmail.com>
 <20171025184857.yhn5f3cegluxsinl@nataraja>
Message-ID: <CAKKcpk-E2VjM2bS0a+Eem0zy=u-VKAyxZf_9JSA8_jHLzctPFQ@mail.gmail.com>

Hi Harald

We want to test TX chain power on timeslot basis.

Currently as all timeslots are enabled, I see power coming in all timeslots.

But if I want to make only alternate timeslot active, I tried changing
slotmask as 10101010 in bts conf file. I also tried to change in code in
trx_if.c.

But I don't see any change in power.

I am using osmo-bts-trx and osmo-trx.

Let me know if this is clear.

Regards
Mayuri

On Thu, Oct 26, 2017 at 12:18 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Mayuri,
>
> from your e-mail it's unfortunately not clear what exactly you are trying
> to achieve.  Please fill us in on the bigger picture so we can get an idea
> of how to help.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171026/20e46129/attachment.htm>

From laforge at gnumonks.org  Thu Oct 26 07:08:10 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 26 Oct 2017 09:08:10 +0200
Subject: Support in using slotmask
In-Reply-To: <CAKKcpk-E2VjM2bS0a+Eem0zy=u-VKAyxZf_9JSA8_jHLzctPFQ@mail.gmail.com>
References: <CAKKcpk9koRzmwDJjOtRycCfpEE-MtUrm5+7y9DN+T7fP2SZbwg@mail.gmail.com>
 <20171025184857.yhn5f3cegluxsinl@nataraja>
 <CAKKcpk-E2VjM2bS0a+Eem0zy=u-VKAyxZf_9JSA8_jHLzctPFQ@mail.gmail.com>
Message-ID: <20171026070810.xjqbpruvoy6hkxin@nataraja>

Hi Mayuri,

On Thu, Oct 26, 2017 at 09:26:11AM +0530, Mayuri Tendulkar wrote:
> We want to test TX chain power on timeslot basis.

I see.

> Currently as all timeslots are enabled, I see power coming in all timeslots.

This is the correct behavior as per 3GPP specs for C0 (TRX 0) of a BTS,
which must always operate at constant full power.  Transmiting only
selective timeslots is only permitted for TRX1..N but not for TRX0.  I
understand you are not in normal operation but in a test setup, but the
code was written for normal operation :)

So my first question would be: Is it possible for you to do those tests
on TRX1..N of your BTS, or does it have to be on TRX0?  If it has to be
TRX0, we would most likely need to develop some (small) changes to
accomodate that.

On TRX1..N you can use the BSC command
	"bts <0-255> trx <0-255> timeslot <0-7> pdch (activate|deactivate)"
to activate a given timeslot or deactivate it.  It can be used at the
"enable" node of the BSC/NITB.

Unless you have valid uplink bursts in your test setup, you should also use
	"radio-link-timeout infinite"
which is a configuration command at the "bts" node in BSC/NITB.

> But if I want to make only alternate timeslot active, I tried changing
> slotmask as 10101010 in bts conf file. I also tried to change in code in
> trx_if.c.

This setting is a logical setting, it only affects which slots the L2/L3
will ever allocate/activate/use.  The purpose is (I believe) to work on
systems which have too limited processing power to handle all 8 slots.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From motosingh at yahoo.co.uk  Fri Oct 27 12:44:18 2017
From: motosingh at yahoo.co.uk (Dees)
Date: Fri, 27 Oct 2017 12:44:18 +0000 (UTC)
Subject: Looking to see if I can test 3g hNodeB with HNBGW implementation on
 Osmo
References: <630056826.8160744.1509108258253.ref@mail.yahoo.com>
Message-ID: <630056826.8160744.1509108258253@mail.yahoo.com>

Hi all,
Very new to Osmo.
Wondering? Osmo has full stack support for Iuh, if yes is there any guidance or wiki page.
Kind regards,Dees
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171027/ebebde63/attachment.htm>

From laforge at gnumonks.org  Fri Oct 27 15:09:02 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 27 Oct 2017 17:09:02 +0200
Subject: Looking to see if I can test 3g hNodeB with HNBGW implementation
 on Osmo
In-Reply-To: <630056826.8160744.1509108258253@mail.yahoo.com>
References: <630056826.8160744.1509108258253.ref@mail.yahoo.com>
 <630056826.8160744.1509108258253@mail.yahoo.com>
Message-ID: <20171027150902.56ddl5eadjjtisro@nataraja>

Hi!

On Fri, Oct 27, 2017 at 12:44:18PM +0000, Dees wrote:
> Very new to Osmo.

Welcome.

> Wondering? Osmo has full stack support for Iuh, if yes is there any guidance or wiki page.

I'm sorry to be frank, but I think you will have seen the "search" bar
on the top right of the osmocom.org project homepage?  Please read up
and ask questions after you went through what has been published. Thanks
for your kind attention.

http://osmocom.org/search?q=iuh

will have many links, including

http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box

and that page has a section about OsmoHNBGW.  Also you will find links
like http://osmocom.org/news/67 that should have clearly answered your
question.

> Kind regards,Dees

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From motosingh at yahoo.co.uk  Fri Oct 27 15:26:57 2017
From: motosingh at yahoo.co.uk (Dees)
Date: Fri, 27 Oct 2017 15:26:57 +0000 (UTC)
Subject: Looking to see if I can test 3g hNodeB with HNBGW
 implementation on Osmo
In-Reply-To: <20171027150902.56ddl5eadjjtisro@nataraja>
References: <630056826.8160744.1509108258253.ref@mail.yahoo.com>
 <630056826.8160744.1509108258253@mail.yahoo.com>
 <20171027150902.56ddl5eadjjtisro@nataraja>
Message-ID: <1029696069.8357139.1509118017283@mail.yahoo.com>

Thank you indeed, Harald.
I found more info on this and config script as well which is helpful.
It would be nice for someone like me a novice on osm to land on a wiki page which gives all info rather having to search or to ask the forum. This wiki was very helpful.
Getting Started with 3G - Cellular Infrastructure - Open Source Mobile Communications

  
|  
|   |  
Getting Started with 3G - Cellular Infrastructure - Open Source Mobile Communications
 Redmine  |  |

  |

 

Kind regards,Dees


      From: Harald Welte <laforge at gnumonks.org>
 To: Dees <motosingh at yahoo.co.uk> 
Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
 Sent: Friday, 27 October 2017, 16:10
 Subject: Re: Looking to see if I can test 3g hNodeB with HNBGW implementation on Osmo
   
Hi!

On Fri, Oct 27, 2017 at 12:44:18PM +0000, Dees wrote:
> Very new to Osmo.

Welcome.

> Wondering? Osmo has full stack support for Iuh, if yes is there any guidance or wiki page.

I'm sorry to be frank, but I think you will have seen the "search" bar
on the top right of the osmocom.org project homepage?? Please read up
and ask questions after you went through what has been published. Thanks
for your kind attention.

http://osmocom.org/search?q=iuh

will have many links, including

http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box

and that page has a section about OsmoHNBGW.? Also you will find links
like http://osmocom.org/news/67 that should have clearly answered your
question.

> Kind regards,Dees

-- 
- Harald Welte <laforge at gnumonks.org>? ? ? ? ? http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300 175-7 Ch. A6)


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171027/89a0d060/attachment.htm>

From jenkins at lists.osmocom.org  Sat Oct 28 16:09:54 2017
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Sat, 28 Oct 2017 16:09:54 +0000 (GMT)
Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?=
 =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1653?=
Message-ID: <610350023.31.1509206994334.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1653/display/redirect>

------------------------------------------
[...truncated 1.84 MB...]
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory,
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
binaries/Makefile.am: installing 'aux_config/depcomp'
test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or
test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or
test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or
test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo)
test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or
test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or
test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or
test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo)
+ ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for LIBXML2... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating def_frame/Makefile
config.status: creating def_list/Makefile
config.status: creating binaries/Makefile
config.status: creating test_apps/Makefile
config.status: creating libsmpp34.pc
config.status: creating aux_config/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.12.10-05bc > .version-t && mv .version-t .version
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Making all in binaries
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o
mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c
mv -f .deps/core.Tpo .deps/core.Po
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c
make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'.  Stop.
make[2]: *** Waiting for unfinished jobs....
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1
mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po
mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo
mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Makefile:368: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 454 C/C++ compilation units (100%) successfully

454 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From hwelte at sysmocom.de  Sat Oct 28 22:00:59 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Sun, 29 Oct 2017 00:00:59 +0200
Subject: New "osmocom:latest" package feed
Message-ID: <20171028220059.7znzjsn3ae3hgbmg@nataraja>

Dear Osmocom community,

since the NITB-split has completed, and we have integrated 3G fully
into master, and also merged nitb-split and nitb packages in one
feed, the next step on the agenda was to create packages/feeds that
are more stable than "nightly".

After a long day of "release engineering" work and related fixes,
starting from today, Osmocom not only has the "osmocom:nightly" feed
tracking the "master of the day" of all repositories.

We now also have a "osmocom:latest" feed for various Debian and Ubuntu
GNU/Linux distributions which contains packages for the last tagged
version of each source code repository.

The setup is fairly similar to that of the "osmocom:nightly" packages
and is described at
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds

I've also removed all known references to Nightly_Builds on the wiki and
replaced it with a reference to the new Binary_Packages page explaining
the differences between Nightly_Builds and Latest_Builds:
https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages

As you can see at
https://build.opensuse.org/project/monitor/network:osmocom:latest
almost all the packages are building already.  I intend to fix the
remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly.

-- 
- Harald Welte <hwelte at 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


From laforge at gnumonks.org  Sun Oct 29 11:02:06 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Oct 2017 12:02:06 +0100
Subject: Packiging: Install config files? Examples only?
Message-ID: <20171029110206.lflnwg5cppuxqhvt@nataraja>

Dear Community,

while working on the "osmocom:latest" builds the last few days, I noticed
that some packages (notably osmo-pcu) install a config file to /etc/osmocom,
while most other packages simply install some example config files to
/usr/share/doc/* and don't create either /etc/osmocom nor any config files
in it - despite the systemd jobs depending on it.

For sure, the behavior should be unified across all Osmocom packages, but
in which way?

What is the best practise here?  What do our users expect?

Let's have a discussion here and note the conclusion in
https://osmocom.org/issues/2602 before implementing it.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Oct 29 12:23:35 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Oct 2017 13:23:35 +0100
Subject: RFC: gerrit verifcations as Jenkins Job Builder YAML file
In-Reply-To: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
References: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
Message-ID: <20171029122335.igg32zz6hsdgav4x@nataraja>

Dear Osmocom community,

On Tue, Sep 12, 2017 at 02:25:04PM +0200, Andr? Boddenberg wrote:
> I've created a prototyp'ish JJB YAML file [1] that holds all current
> gerrit verification jobs on jenkins.osomocom.org. 

it's been about six weeks since Andre contributed his work on converting
our hand-creafted gerrit job descriptions into something that's much
cleaner and easier to maintain.

I've taken the liberty to finally deploy this (after another pass
manually through all job definitions to ensure we didn't miss any
changes).  The longer we wait, the more complex the differences between
the yml and the acual jobs will get, and we can start from scratch.

As a result, all gerrit jenkins jobs are now the result of
http://git.osmocom.org/osmo-ci/tree/jobs/gerrit-verifications.yml

There is not yet a job to automatically deploy any changes in
osmo-ci.git to jenkins, but I think it's definitely an improvement.

All jobs generated this way have a clear warning in their description
that they should not be modified manually.  Please kindly observe this
and instead update the yml and deply with
	"jenkins-jobs update ./jobs/gerrit-verifications.yml"
instead.

I apologize in advance for any fall-out from this change.  We'll only see
if it works once people start pushing patches to gerrit.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Oct 29 12:33:26 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Oct 2017 13:33:26 +0100
Subject: RFC: Getting rid of FreeBSD build testing
In-Reply-To: <20170905205511.s7kpe4354zqgnksx@nataraja>
References: <20170905205511.s7kpe4354zqgnksx@nataraja>
Message-ID: <20171029123326.36ch272ut4fvlaza@nataraja>

Hi!

Since there were not any FreeBSD users asking us to keep the FreeBSD builds,
I think we should go ahead with removing the build testing on that platform.

For the gerrit jobs it's easy, my proposed patch can be found in
https://gerrit.osmocom.org/#/c/4576/

Let's wait if the jenkins-job-builder gerrit jobs work as expected before
merging/deploying this.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From alexander.chemeris at gmail.com  Sun Oct 29 15:44:29 2017
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sun, 29 Oct 2017 19:44:29 +0400
Subject: OsmoNITB Migration Guide
Message-ID: <CABmJbFXDwiGuoyBTeHObP5D_vHxwcsiRXcxKraU2A4J60mCagA@mail.gmail.com>

Hi Neels,

I was reading the subj and I have a couple questions:

> Note that not all information is copied to the hlr.db, just IMSI and 2G auth tokens.

Are at least extension values migrated as well? Could you explicitly
list what is not migrated?
Maybe just list exact list of values migrated to make sure there is no
confusion by users?

> # ---------- to OsmoBSC:

Is '#' a valid comment for Osmocom files? I always saw ';' used instead.

And one note:

Not sure if you have time for that, but what would be really helpful
is a table with all OsmoNITB, OsmoBSC and OsmoMSC configuration values
listed and three columns showing where the value belongs. That would
make it much easier to users to migrate and (I would expect) reduce
the number of questions on the mailing list. Something like this:

Configuration value                      OsmoNITB     OsmoBSC    OsmoMSC
network / network country code 901         yes          no         yes
msc / msc-addr msc_remote                   no         yes          no


PS Great work! Keep it up!

-- 
Regards,
Alexander Chemeris.
CTO/Founder, Fairwaves, Inc.
https://fairwaves.co


From jenkins at lists.osmocom.org  Sun Oct 29 16:09:39 2017
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Sun, 29 Oct 2017 16:09:39 +0000 (GMT)
Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?=
 =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1654?=
In-Reply-To: <610350023.31.1509206994334.JavaMail.jenkins@jenkins.osmocom.org>
References: <610350023.31.1509206994334.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <1662183441.35.1509293379872.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1654/display/redirect>

------------------------------------------
[...truncated 1.79 MB...]
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory,
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
binaries/Makefile.am: installing 'aux_config/depcomp'
test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or
test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or
test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or
test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo)
test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or
test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or
test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or
test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo)
+ ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for LIBXML2... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating def_frame/Makefile
config.status: creating def_list/Makefile
config.status: creating binaries/Makefile
config.status: creating test_apps/Makefile
config.status: creating libsmpp34.pc
config.status: creating aux_config/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.12.0.11-0f76 > .version-t && mv .version-t .version
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Making all in binaries
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o
mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1
mv -f .deps/core.Tpo .deps/core.Po
mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c
make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'.  Stop.
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo
mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Makefile:368: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 454 C/C++ compilation units (100%) successfully

454 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From nhofmeyr at sysmocom.de  Mon Oct 30 04:43:18 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 30 Oct 2017 05:43:18 +0100
Subject: RFC: gerrit verifcations as Jenkins Job Builder YAML file
In-Reply-To: <20171029122335.igg32zz6hsdgav4x@nataraja>
References: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
 <20171029122335.igg32zz6hsdgav4x@nataraja>
Message-ID: <20171030044318.GA23397@my.box>

On Sun, Oct 29, 2017 at 01:23:35PM +0100, Harald Welte wrote:
> I apologize in advance for any fall-out from this change.  We'll only see
> if it works once people start pushing patches to gerrit.

Thanks for taking this step, I didn't have the guts yet. I've fixed quite some
fallout, take a look at the commits I blatantly pushed directly to osmo-ci
master.

Having these textual config files is a huge relief from clicking around in slow
web UIs. Kudos to Andr?!

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171030/ca399caa/attachment.bin>

From jenkins at lists.osmocom.org  Mon Oct 30 16:10:19 2017
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Mon, 30 Oct 2017 16:10:19 +0000 (GMT)
Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?=
 =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1655?=
In-Reply-To: <1662183441.35.1509293379872.JavaMail.jenkins@jenkins.osmocom.org>
References: <1662183441.35.1509293379872.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <1247834049.39.1509379819923.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1655/display/redirect>

------------------------------------------
[...truncated 1.79 MB...]
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory,
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
binaries/Makefile.am: installing 'aux_config/depcomp'
test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or
test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or
test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or
test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo)
test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or
test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or
test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or
test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo)
+ ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for LIBXML2... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating def_frame/Makefile
config.status: creating def_list/Makefile
config.status: creating binaries/Makefile
config.status: creating test_apps/Makefile
config.status: creating libsmpp34.pc
config.status: creating aux_config/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.12.0.11-0f76 > .version-t && mv .version-t .version
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Making all in binaries
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o
mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1
mv -f .deps/core.Tpo .deps/core.Po
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c
make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'.  Stop.
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo
mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo
mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Makefile:368: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 454 C/C++ compilation units (100%) successfully

454 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From nhofmeyr at sysmocom.de  Mon Oct 30 17:16:00 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 30 Oct 2017 18:16:00 +0100
Subject: Looking to see if I can test 3g hNodeB with HNBGW implementation
 on Osmo
In-Reply-To: <1029696069.8357139.1509118017283@mail.yahoo.com>
References: <630056826.8160744.1509108258253.ref@mail.yahoo.com>
 <630056826.8160744.1509108258253@mail.yahoo.com>
 <20171027150902.56ddl5eadjjtisro@nataraja>
 <1029696069.8357139.1509118017283@mail.yahoo.com>
Message-ID: <20171030171600.GA9921@my.box>

Hi Dees,

> Getting Started with 3G - Cellular Infrastructure - Open Source Mobile Communications

Note that this wiki page is currently outdated in that we have 3G support in
our new master branches, while that wiki page is still on using a 3G branch of
the old openbsc.git repos.

The page shall be updated soon (or maybe merged to the Osmocom Network In The
Box wiki page?).

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171030/023594ea/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 30 17:39:26 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 30 Oct 2017 18:39:26 +0100
Subject: New "osmocom:latest" package feed
In-Reply-To: <20171028220059.7znzjsn3ae3hgbmg@nataraja>
References: <20171028220059.7znzjsn3ae3hgbmg@nataraja>
Message-ID: <20171030173926.GB9921@my.box>

On Sun, Oct 29, 2017 at 12:00:59AM +0200, Harald Welte wrote:
> After a long day of "release engineering" work and related fixes,
> starting from today, Osmocom not only has the "osmocom:nightly" feed
> tracking the "master of the day" of all repositories.

Yay, excellent!

So we can make those three-monthly release feeds we're planning to start in
december by essentially pinning the versions of a 'latest' build. (They won't
really be "stable" releases, just pinned ones.)

We could theoretically also just copy the 'latest' binaries on a given day to a
different download folder without maintaining OBS builds ... but probably
better to do actual builds instead for easier "backport" releasing if needed.

We'll probably do a release tagging round in all repositories for each such
cycle, 4 times a year, and are free to do more release tags in-between to make
'latest' benefit from fixes or features.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171030/c7013af9/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 30 17:44:03 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 30 Oct 2017 18:44:03 +0100
Subject: Packiging: Install config files? Examples only?
In-Reply-To: <20171029110206.lflnwg5cppuxqhvt@nataraja>
References: <20171029110206.lflnwg5cppuxqhvt@nataraja>
Message-ID: <20171030174403.GC9921@my.box>

On Sun, Oct 29, 2017 at 12:02:06PM +0100, Harald Welte wrote:
> Dear Community,
> 
> while working on the "osmocom:latest" builds the last few days, I noticed
> that some packages (notably osmo-pcu) install a config file to /etc/osmocom,
> while most other packages simply install some example config files to
> /usr/share/doc/* and don't create either /etc/osmocom nor any config files
> in it - despite the systemd jobs depending on it.
> 
> For sure, the behavior should be unified across all Osmocom packages, but
> in which way?

The OE builds generally install in /etc/osmocom. We should also keep the
/usr/share/doc/* ones, because some programs install several alternative
configs. But probably the debian should also install one default version to
/etc/osmocom. I guess they should even be the minimal versions as from Osmocom
Network In The Box, and enriched with commented-out sections for common
additions.

So much documenting to do!

And I haven't yet fully verified the Osmocom Network In The Box configs, I
might add default/minimal config files to the various repositories while I
verify those. (One of the highest items on my current todo list.)

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171030/180c5300/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 30 17:51:52 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 30 Oct 2017 18:51:52 +0100
Subject: OsmoNITB Migration Guide
In-Reply-To: <CABmJbFXDwiGuoyBTeHObP5D_vHxwcsiRXcxKraU2A4J60mCagA@mail.gmail.com>
References: <CABmJbFXDwiGuoyBTeHObP5D_vHxwcsiRXcxKraU2A4J60mCagA@mail.gmail.com>
Message-ID: <20171030175152.GD9921@my.box>

On Sun, Oct 29, 2017 at 07:44:29PM +0400, Alexander Chemeris wrote:
> Hi Neels,
> 
> I was reading the subj and I have a couple questions:
> 
> > Note that not all information is copied to the hlr.db, just IMSI and 2G auth tokens.
> 
> Are at least extension values migrated as well? Could you explicitly
> list what is not migrated?

Ah, I think I forgot to mention MSISDN, it is also migrated.

> Maybe just list exact list of values migrated to make sure there is no
> confusion by users?

There's two sides to that, each description of what is migrated is likely to
become outdated whenever we change what is being migrated...
Maybe we should point to some osmo-hlr-db-tool cmdline help instead.

But yes.

> Is '#' a valid comment for Osmocom files? I always saw ';' used instead.

both # and ; work -- I found out while hacking VTY code recently ;)

> Not sure if you have time for that, but what would be really helpful
> is a table with all OsmoNITB, OsmoBSC and OsmoMSC configuration values
> listed and three columns showing where the value belongs. That would
> make it much easier to users to migrate and (I would expect) reduce
> the number of questions on the mailing list. Something like this:
> 
> Configuration value                      OsmoNITB     OsmoBSC    OsmoMSC
> network / network country code 901         yes          no         yes
> msc / msc-addr msc_remote                   no         yes          no

I thought the '#' comments were good enough?
The result of such a table would be the entire config file with dozens of
identical 'yes | no' markers on the right?

Maybe I'm not understanding what you mean ... so may I suggest that you write
one? I'll be happy to review that.

BTW, I also want to figure out which parts really need to be issued twice, and
which are just leftovers from the openbsc.git split...

> PS Great work! Keep it up!

Thanks! And likewise! :)

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171030/b7a46c87/attachment.bin>

From keith at rhizomatica.org  Mon Oct 30 18:12:03 2017
From: keith at rhizomatica.org (Keith)
Date: Mon, 30 Oct 2017 12:12:03 -0600
Subject: GPRS EXperiments
Message-ID: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org>

Hi List!

As there isn't so much about GPRS on here, I though I might
write something about experiments over the last couple of
weeks with data inside and outside of the lab.

I've installed up to date versions of osmo-bts and osmo-pcu
on sysmobts 2050 hardware and it's working great!
Dynamic channels are really nice, with half rate TCH and AMR
working perfectly. Thanks for all that work!

The question for this experiment was if it was going to be
feasible to actually do anything with several hundred data
hungry spying devices.... I mean mobile phones on the network.

For the traffic control, I setup a local blacklisting or
whitelisting dns server.
I've tried both. Blacklisting the worst culprits would be
nice, but in practice I think I'll have to go for
whitelisting only the intended permitted services.
I configured pcodns1 in the ggsn to point to this DNS
server, AND I setup a port 53 redirect to catch quite a lot
of traffic from android that likes to just talk directly to
8.8.8.8 anyway.

In the wild, some dns request analysis reveals the worst
culprits (this is a very basic analysis) appear to be all
the google update stuff, play store etc, facebook? iCloud,?
(all to be expected) , and certain CDNs. Some research shows
that these CDN companys specialize in delivery of
advertising content inside apps such as mobile platform
games. Such is the sad state of affairs on today's internet.
Fortunately, we have iptables and ip sets and we have AS
blocks assigned to certain bandwidth hungry corporations :-)

So turns out it seems quite feasible to supply service for
text messages with certain popular IM services to many phones.
Short voice clips worked quite well in the lab tests,?
although support for media such as pictures and videos was
not so great. I have yet to successfully send an image
(sourced via device camera within the app) over a "secret"
chat with Telegram messenger.

As this is not a very low level report, rather intended as
some light reading :) I also have a question in a similar
light vein.

I'm still getting to grips with the log messages available
in the pcu , the sgsn and not so much the ggsn, and I'm
observing and learning the sequence of events, so at some
point I should be able to present a better report about this
with some relevant traces and better analysis.

For now, In the lab tests I am constantly monitoring the RF
uplink; I observe that a phone will attach and then go
quiet. A foreground running app may report that it is
"connecting" or some such, and the little arrows may be
flashing to show that apparently we are transmitting data,
but there is nothing on the uplink. My guess here is the OS
has sent something and the baseband is saying yes yes doing
it.. but the baseband at the same time is waiting for
something from the network (and not getting it)?

This situation can persist for some time.. several minutes.
I have observed that if I initiate any data transfer from
the network side then the uplink is established. By the same
token, If I transfer a file from the network (http download
or some such), the same applies. The link stays active and
the IM chat session is very responsive alongside the file
transfer. Shortly after the file transfer completes, the
uplink is quiet again and the latency in the IM session
becomes a problem.

>From a UX point of view.. Let me put it this way.. I can
start an IM chat, send a message.. but then we get to this
quiet uplink sitation and the messages stop sending.. so
from the user's point of view it's frustrating. the phone
looks like it's transmitting.. until there are timeouts and
disconnections and the app may show some indication to the
user that it is having trouble connecting to the network.

However if I run something on the network side like a script
that sends one ping to the phone every ten seconds, this
keeps the connection 'alive' and the IM session is much more
satisfactory for the user.

I should note I believe I observe this also on commercial
networks? in some places like certain Berlin U-bahn stations
where you can still find (only) GPRS data coverage. Also, a
more scientific report is needed, but I seem to observe some
phones behaving "better" than others, as in being a little
more active on the uplink. Maybe it is related to power
saving configuration?

The not very low level and scientific question here is: Is
this kind of thing tunable with gprs parameters?
Any tips on which ones to play with? ( Quite happy to wait
until I can send a more useful? report too! )

Thanks!

Keith.







From laforge at gnumonks.org  Mon Oct 30 20:28:06 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Oct 2017 21:28:06 +0100
Subject: New "osmocom:latest" package feed
In-Reply-To: <20171030173926.GB9921@my.box>
References: <20171028220059.7znzjsn3ae3hgbmg@nataraja>
 <20171030173926.GB9921@my.box>
Message-ID: <20171030202806.cfeeynqemkkv7bul@nataraja>

Hi Neels,

On Mon, Oct 30, 2017 at 06:39:26PM +0100, Neels Hofmeyr wrote:
> Yay, excellent!

thanks!

> So we can make those three-monthly release feeds we're planning to start in
> december by essentially pinning the versions of a 'latest' build. (They won't
> really be "stable" releases, just pinned ones.)

ACK.

> We could theoretically also just copy the 'latest' binaries on a given day to a
> different download folder without maintaining OBS builds ... but probably
> better to do actual builds instead for easier "backport" releasing if needed.

we should have "network:osmocom:release-xyz" feeds for each of the releases we
create.

> We'll probably do a release tagging round in all repositories for each such
> cycle, 4 times a year, and are free to do more release tags in-between to make
> 'latest' benefit from fixes or features.

I'm wondering if it wouldn't make more sense to have git branches (as opposed to tags)
for those "overall project releases".  This way we could actually - if needed - add
fixes or other backports to the respective release branch in the repository, and 
the OBS builds for that release would simply follow those branches?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From jenkins at lists.osmocom.org  Tue Oct 31 16:09:52 2017
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Tue, 31 Oct 2017 16:09:52 +0000 (GMT)
Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?=
 =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1656?=
In-Reply-To: <1247834049.39.1509379819923.JavaMail.jenkins@jenkins.osmocom.org>
References: <1247834049.39.1509379819923.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <225533143.43.1509466192187.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1656/display/redirect>

------------------------------------------
[...truncated 1.84 MB...]
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory,
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9:   'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8:   'test_pdu/Makefile.am' included from here
binaries/Makefile.am: installing 'aux_config/depcomp'
test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or
test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or
test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or
test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo)
test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or
test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or
test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or
test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo)
+ ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for LIBXML2... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating def_frame/Makefile
config.status: creating def_list/Makefile
config.status: creating binaries/Makefile
config.status: creating test_apps/Makefile
config.status: creating libsmpp34.pc
config.status: creating aux_config/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.12.0.11-0f76 > .version-t && mv .version-t .version
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Making all in binaries
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c  -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o
mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1
mv -f .deps/core.Tpo .deps/core.Po
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS  -g -O2 -Wall -fPIC  -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c
make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'.  Stop.
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo
mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po
mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Makefile:368: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 454 C/C++ compilation units (100%) successfully

454 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From hwelte at sysmocom.de  Tue Oct 31 18:56:00 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Tue, 31 Oct 2017 19:56:00 +0100
Subject: Want to do paid work on Osmocom? sysmocom is hiring
Message-ID: <20171031185600.ca6izqakkcvg43nu@nataraja>

Dear Osmocom community,

I would like to point out that at sysmocom, we're currently (again)
hiring [1].  If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.

sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project.  Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.

Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.

We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G.  We believe in
working upstream, no open core or dual licensing.

If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs at sysmocom.de

Thanks,
	Harald

p.s.: I hope this kind of message is not disturbing to anyone.  I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified.  The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.

[1] https://www.sysmocom.de/jobs/

-- 
- Harald Welte <hwelte at 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


From debian at alteholz.de  Tue Oct 31 22:11:23 2017
From: debian at alteholz.de (Thorsten Alteholz)
Date: Tue, 31 Oct 2017 23:11:23 +0100 (CET)
Subject: .deb updates in Debian/Ubuntu repos
In-Reply-To: <a00841fd-e2de-b9f9-b20b-e6ae7a3778ae@sysmocom.de>
References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
 <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
 <a00841fd-e2de-b9f9-b20b-e6ae7a3778ae@sysmocom.de>
Message-ID: <alpine.DEB.2.02.1710311958310.15400@jupiter.server.alteholz.net>

Hi,

On Tue, 24 Oct 2017, Max wrote:
> There's another question related to .deb packaging which emerged recently: how do we
> update libraries properly?
>
> Let's take concrete example - libosmo-netif, current version is 0.0.7; libversion is
> 3:0:0
>
> I'd like to release new version: 0.0.8, libversion is 4:0:1
>
> What do I do with debian/?

if there is a SONAME change, the package name should change. The link in 
the dev package should point to the new version. And ...

> The library package named libosmonetif3.install
> According to https://wiki.debian.org/TransitionBestPractices it should be renamed to
> libosmonetif4.install because we're changing "current" component of libversion.

... yes, this as well (not only this file but all others that belong to 
this package as well)

> We should also change debian/control to reflect this rename, but what about
> "Conflicts:" in there?
> I've tried reading
> https://debian-handbook.info/browse/stable/sect.package-meta-information.html but
> still not sure how it should be applied in case of shared libraries.
>
> Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2?
> Shall we use /Replaces instead? If so, for which version(s)?

Replaces: is only for two packages with the same functionality, so a 
Conflicts: would be right. It should be for each version available 
earlier (there might be an old version left during an upgrade).

> Also, am I even reading this in the right place or there're some better docs
> recommended for Debian library packaging?

The Debian Handbook is written by a well known Debian Developer, so this 
is a good starting point (though there seems to be no version for Stretch 
yet). There is even a package called debian-handbook. There is also the 
Maintainer guide[1] and of course the Debian policy[2].

It would be also nice to have versioned Depends:
For example libosmo-netif depends on libosmo-abis, but what would be the 
minimal version that really satisfies this dependency for the latest 
libosmo-netif?

   Thorsten

[1] https://www.debian.org/doc/manuals/maint-guide/
[2] https://www.debian.org/doc/debian-policy/



From debian at alteholz.de  Tue Oct 31 22:11:33 2017
From: debian at alteholz.de (Thorsten Alteholz)
Date: Tue, 31 Oct 2017 23:11:33 +0100 (CET)
Subject: .deb updates in Debian/Ubuntu repos
In-Reply-To: <879a2f20-b8f1-1e3c-1483-07ce0e140d7d@sysmocom.de>
References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de>
 <alpine.DEB.2.02.1710182252150.32646@jupiter.server.alteholz.net>
 <879a2f20-b8f1-1e3c-1483-07ce0e140d7d@sysmocom.de>
Message-ID: <alpine.DEB.2.02.1710311952520.15400@jupiter.server.alteholz.net>

Hi,

On Fri, 20 Oct 2017, Max wrote:
> I've submitted few patches to it recently but that's just some stuff I've spotted by
> accident when looking at lintian output. Are there some tools/docs about it? I mean
> what's the actual maintenance procedure?

Taking care of all the things lintian complains about, is a good start. 
The file format is described in [1]. The procedure is to manually check each 
file whether there are any license information in it. As tools like 
licensecheck and debmake and whatever are good, but might miss strange 
formats, the best thing is to look into each file. That's why this is the 
most boring part of maintenance ..

> I'm not promising I'll keep it 100% updated all the time :-) but at least we can
> document this in the wiki and maybe try to plug it into release automation scripts.

That would be fine.

   Thorsten

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/