From holger at freyther.de  Sat Oct  1 13:48:03 2016
From: holger at freyther.de (Holger Freyther)
Date: Sat, 1 Oct 2016 15:48:03 +0200
Subject: bts lchan loopback vty command -- was: Query on run time control
 of network with VTY
In-Reply-To: <CAKKcpk_BerWUvDV7RqJwNY+or_qqeyTo4tKHgFzqXPsZWPLdwQ@mail.gmail.com>
References: <CAM5ro7uyFA5X7_UaL0NWgS0aN0ykW3vnHzo5zX8t_ppZjXUJSw@mail.gmail.com>
 <E9655EA7-4BA7-4F2C-BBF5-15D0620DA298@freyther.de>
 <CAM5ro7thf4K_-38Oh=TZrt1w42A=EUhi9MPsCn8t8cnC-8a=QQ@mail.gmail.com>
 <20160921151627.GE1463@dub7>
 <CAKKcpk_BerWUvDV7RqJwNY+or_qqeyTo4tKHgFzqXPsZWPLdwQ@mail.gmail.com>
Message-ID: <3F642603-A891-439A-85BF-E9E6483CDF73@freyther.de>


> On 30 Sep 2016, at 21:20, Mayuri Tendulkar <mayuri.tendulkar at gmail.com> wrote:
> 
> Thanks Neels.

Dear Mayuri,


> Where we can get more information on this? We would like to use this loopback for BER measurements.
> 
> Is it suitable to do that?

a Free Software project like Osmocom exists because developers want to collaborate and it survives by people donating some (or a lot) of their time to make it better and companies (like Sysmocom) allowing developers to work on it. In your position I think you have the following options:

a.) Your company contracts someone that knows how to modify osmo-trx to do what you want for your measurement.

b.) You make yourself familiar with osmo-trx, fix/extend the code, write documentation and share it with the community.

either way, please share your findings and result with us.

thank you
	holger

From axilirator at gmail.com  Sun Oct  2 07:11:32 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sun, 2 Oct 2016 13:11:32 +0600
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <8C00661C-EE43-4107-8FBB-FD86EB010CA2@gnumonks.org>
References: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>
 <CAPEnp=Ym+RvE_LSdDf1V97NvSgGOTQZaoE1hwZ36x67WWhW9TA@mail.gmail.com>
 <CAATyM+a6n2xBT9MVtUQG7DcrQGi=7k9TbrN8cqeu56Nz9ygQkw@mail.gmail.com>
 <CAHL+j081uWBUhuC1roOV45FpM=n3f=+ha_YryxjMCk5SFxvbqA@mail.gmail.com>
 <CAPEnp=ZWLo__VLMd7faf8TqK5F9Xzfnujmczr2dRD5kb=PcOuA@mail.gmail.com>
 <8C00661C-EE43-4107-8FBB-FD86EB010CA2@gnumonks.org>
Message-ID: <CAPEnp=bZmoDX+C1DrV_Utt+4pmdUeGzNLzpX9n9j=s9NDj_Org@mail.gmail.com>

Hi Harald,

> Why the code differs, I don't know. Maybe it was
> never completed in conv_gen?

It seems, I found the answer. If you look closer at
gsm0503_coding.c/gsm0503_pdtch_encode(), you will see:

// Around line 1300, CS-2 encoding
// ...

osmo_pbit2ubit_ext(conv, 3, l2_data, 0, 271, 1);
usf = l2_data[0] & 0x7;

osmo_crc16gen_set_bits(&gsm0503_cs234_crc16, conv + 3,
    271, conv + 3 + 271);

memcpy(conv, gsm0503_usf2six[usf], 6);

osmo_conv_encode(&gsm0503_cs2, conv, cB);

//
for (i = 0, j = 0; i < 588; i++)
    if (!gsm0503_puncture_cs2[i])
        cB[j++] = cB[i];

hl_hn = gsm0503_pdtch_hl_hn_ubit[1];

// ...

So, as I understand, this code applies puncture itself.
But in our case, the osmo_conv_encode() applies puncture
too, from the gsm0503_cs2 convolutional code definition.
The same things happens in the gsm0503_pdtch_decode().

There are two possible ways to go in my mind:

1) The simplest way is to merely remove puncture from
   both gsm0503_cs2 and gsm0503_cs3 definitions, but
   it may break some code, which already uses current
   variant.
2) Change exactly the gsm0503_coding.c to use puncture
   from shared convolutional code definitions. For me,
   this way is prefered, but I don't know how to change
   the code yet.

Any opinions?
Does any project use the convolutional code definitions
from 'utils/conv_gen.py'?


With best regards,
Vadim Yanitskiy.

2016-09-29 21:40 GMT+07:00 Harald Welte <laforge at gnumonks.org>:

> From my memory:
>
> * CS1 is rate 1/2 conv code with no puncturing.
> * CS2+3 apply different puncturing amounts on that conv code
> * CS4 has no error correction (=100% puncturing)
>
> Why the code differs, I don't know. Maybe it was never completed in
> conv_gen?
>
> --
> Sent from a mobile device. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161002/1c578731/attachment.htm>

From msuraev at sysmocom.de  Mon Oct  3 16:45:40 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 3 Oct 2016 18:45:40 +0200
Subject: coverity for osmocom projects
In-Reply-To: <20160921210101.GA1210@dub7>
References: <20160921142500.GB1463@dub7>
 <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de>
 <20160921210101.GA1210@dub7>
Message-ID: <93aa51d1-4527-2659-6f39-4d2ebfc81404@sysmocom.de>

Neat.

Who's got admin rights? I've sent requests to be added to osmo-bts,
osmo-trx and libosmo-dsp projects but they are still pending. Also, if I
forgot smth else than please add me there as well - I don't mind some
extra emails from coverity.


On 09/21/2016 11:01 PM, Neels Hofmeyr wrote:
> On Wed, Sep 21, 2016 at 04:41:12PM +0200, Max wrote:
>> Curiously, I see that there are no successful builds for osmo-trx with
>> the advice to contact project owner. Who's that in case of osmo-trx and
>> why builds are failing?
> The reason is very simple -- it is completely omitted from the coverity build
> scripts :)
>
> I could try to add it...
>
> ~Neels
>

-- 
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  5 01:43:02 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 5 Oct 2016 03:43:02 +0200
Subject: problems compiling for sysmobts
Message-ID: <20161005014302.GF3784@my.box>

Hi all,

I'd like to share my odd? interesting? unnerving? experience today.  All I
wanted to do is quickly check something (gerrit #713) on sysmobts, but I faced
a series of problems.

First some sysmobts related problems, later two problems entirely unrelated to
osmocom...


(*)
My sysmobts SDK no longer works: libosmo-abis now requires libortp >= 0.22.0,
but the SDK I have used so far doesn't have that:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160323112523.sh

(I didn't go through it in this sequence, but tried these things:)

a) tried to build a more recent libortp into the installed SDK. It goes fine up
to a point. It takes a bit of work to find and fetch all the repositories that
are required:
git://git.linphone.org/bcunit.git
git://git.linphone.org/bctoolbox.git
git://git.linphone.org/ortp.git
but sadly, bctoolbox wants libpolarssl aka mbedtls
git at github.com:ARMmbed/mbedtls.git
-- which has no automake/autoconf, only a plain Makefile! It also has cmake and
others, but so far I only know how to tell the ./configure script to
cross-compile and install into the SDK, so I kind of gave up on figuring out
cmake for that, for now.

b) just reverted the libortp version bumping commit in libosmo-abis
(15d9b7929d449e4138bcb003c614035bceadc3d1)
Everything compiles and works out, but alas, I get constant very weird
distortion/blip-tones/hickups on the voice channels, a bit of voice still
audible but definitely some bad codec problem. A regression? Is it related to
libortp?  This happens both for a TS config of TCH/H and TCH/F.

c) tried fetching a new SDK from 201310-testing/sdk:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160910200558.sh
This has the same problem with too old libortp. Again I revert the libortp
version bump from libosmo-abis. Same results as above: badly broken voice.

d) tried a new 1.5.4 SDK from 201310-nightly/sdk:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.4-20161004010024.sh
Here libosmo-abis is fine with the libortp it finds, so far so good.
Sadly, this doesn't even do hickuped voice, only low noise on both ends.
So I decided to go back to the SDK that worked for me last time to bisect.
I will post another mail in case I found a regression.


(*)
For half a minute there I wondered why GPRS wasn't working until I remembered
our two-phase-access aka WAIT_ASSIGN problem in osmo-pcu and reverted
f1a7b8fc. With that, GPRS works fine with all of the above. phew ;)


(*)
Entirely unrelated to osmocom: I launch my CN programs from a script that
launches multiple terminals. I happen to use rxvt-unicode for that and always
have for a year. Turns out this time urxvt strips the LD_LIBRARY_PATH
when it is invoked. I still don't know how this changed, but when I drop the
suid that I find for unknown reasons sitting on the urxvt binary's group
('chmod g-s /usr/bin/urxvt'), it lets the LD_LIBRARY_PATH be, and the binaries
run. How did this change from the last time I ran my CN scripts?? No idea.


(*)
Same with sudo: LD_LIBRARY_PATH now all of a sudden gets stripped during my
  sudo ggsn -f -c ggsn.conf
invocation. I use sudo for ggsn to allow establishing tunnels.  Again I didn't
change anything about my scripts, just today it doesn't find the libraries in
/usr/local/lib anymore. I have to manually add it like
  sudo LD_LIBRARY_PATH=/usr/local/lib ggsn ...
but then sudo tells me I'm not allowed to set the env. After searching around,
I add 'SETENV:' to my sudoers file:
  neels   ALL= NOPASSWD:SETENV: /usr/local/bin/ggsn *
This time ggsn starts again like it always used to. How did this change from
last time I ran ggsn this way?? No idea at all.



So my quick test took a bit longer than expected (hasn't started),
and the night has progressed at an alarming rate...
I'll write again when I found anything on the broken voice.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr 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/20161005/e06d5557/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Oct  5 02:49:03 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 5 Oct 2016 04:49:03 +0200
Subject: problems compiling for sysmobts
In-Reply-To: <20161005014302.GF3784@my.box>
References: <20161005014302.GF3784@my.box>
Message-ID: <20161005024903.GG3784@my.box>

On Wed, Oct 05, 2016 at 03:43:02AM +0200, Neels Hofmeyr wrote:
> b) just reverted the libortp version bumping commit in libosmo-abis
> (15d9b7929d449e4138bcb003c614035bceadc3d1)
> Everything compiles and works out, but alas, I get constant very weird
> distortion/blip-tones/hickups on the voice channels, a bit of voice still
> audible but definitely some bad codec problem. A regression?

I have identified voice to be broken on sysmobts-v2 starting from this osmo-bts
commit:

  commit 654175f33bd412671e3ef8cdd65c0689d10f278c
  Refs: 0.4.0-281-g654175f
  Author:     Max <msuraev at sysmocom.de>
  AuthorDate: Sat Sep 17 14:15:03 2016 +0200
  Commit:     Max <msuraev at sysmocom.de>
  CommitDate: Sat Sep 24 15:09:31 2016 +0200

      DTX: check Marker bit to send ONSET to L1

      If Marker bit is set than it's a talkspurt which we have to explicitly
      indicate to L1 by first sending ONSET message and than actual voice
      data in a separate message.

      This change affect sysmobts and LC15 hw.

      Change-Id: I88c41568bcb0d82699f617adc4ad192603dd1bb6
      Related: OS#1750


Going back with osmo-bts to one before this commit fixes all problems with both
1.5.3 SDK versions tested:
> poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160323112523.sh
> poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160910200558.sh

However, the 1.5.4 SDK still produces only noise. It has a newer libortp, and
note that the litecell15 instructions include a choice of libortp 0.16.5,
explicitly *not* a newer version, so it might be related to that.


To summarize, to have a working setup on sysmobts, I still need to:
- use a 1.5.3 SDK
- libosmo-abis: git revert 15d9b7929d449e4138bcb003c614035bceadc3d1
- osmo-bts: git checkout eb08a87be52bf55a78c12689f1e5c7cff627cbbc

GPRS is not affected, works well with all of the above (except for the old
two-phase-access OS#1756 issue).

Maybe I'll figure out how to compile the mbedtls into the 1.5.3 SDK or build
without mbedtls, allowing a newer libortp: if voice is reduced to noise by
that, we would know whether libortp's HEAD has a problem for us.

~Neels


-- 
- 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/20161005/712ceeb5/attachment.bin>

From msuraev at sysmocom.de  Wed Oct  5 08:17:08 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 5 Oct 2016 10:17:08 +0200
Subject: problems compiling for sysmobts
In-Reply-To: <20161005024903.GG3784@my.box>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
Message-ID: <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>

Hi.

This might be related to commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a
in osmobts - see https://projects.osmocom.org/issues/1661
If you roll-back this commit, does voice re-appear?

Also, why do you have to use 1.5.3 instead of 1.5.4?

On 10/05/2016 04:49 AM, Neels Hofmeyr wrote:
>
> However, the 1.5.4 SDK still produces only noise. It has a newer libortp, and
> note that the litecell15 instructions include a choice of libortp 0.16.5,
> explicitly *not* a newer version, so it might be related to that.

-- 
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  6 14:01:46 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 6 Oct 2016 16:01:46 +0200
Subject: problems compiling for sysmobts
In-Reply-To: <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
 <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
Message-ID: <20161006140146.GC8015@my.box>

[SDK 1.5.4 has no voice]
> This might be related to commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a
> in osmobts - see https://projects.osmocom.org/issues/1661

osmo-bts has no commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a.
...you mean libosmo-abis.

> If you roll-back this commit, does voice re-appear?

Wow, it actually does! I was pretty sure this would not fix anything. I have
discussed in detail in OS#1661, and see https://gerrit.osmocom.org/1011 .


A pressing issue which you seemingly ignored is that your osmo-bts commit
654175f33bd412671e3ef8cdd65c0689d10f278c breaks voice on SysmoBTS. Could you
grab a sysmoBTS and verify+fix it soon? Otherwise revert.

~Neels

-- 
- 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/20161006/4e157d2e/attachment.bin>

From msuraev at sysmocom.de  Thu Oct  6 14:09:18 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 6 Oct 2016 16:09:18 +0200
Subject: problems compiling for sysmobts
In-Reply-To: <20161006140146.GC8015@my.box>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
 <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
 <20161006140146.GC8015@my.box>
Message-ID: <bf8fd8b1-878a-32a5-2aab-23e82f5cfb97@sysmocom.de>

Hi.

I have not ignored anything, I've pointed to commit which I suspect
could have broken voice (as you rightfully pointed out it's in
libosmo-abis). Could you clarify if reverting this commit in
libosmo-abis fixes the voice for sysmobts master? Or in addition to
reverting c77c2a6aa13accbc558888ab788d1148eb9aeb1a in libosmo-abis I've
got to checkout some later commit in sysmobts?

If reverting commit in libosmo-abis indeed fixes voice for sysmobts sdk
1.5.4 than please send patch for review (add me as reviewer).

Right now I'm working on DTX rewrite using FSM which might fix sysmobts
if it's indeed broken (after fixing libosmo-abis).

On 10/06/2016 04:01 PM, Neels Hofmeyr wrote:
> [SDK 1.5.4 has no voice]
>> This might be related to commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a
>> in osmobts - see https://projects.osmocom.org/issues/1661
> osmo-bts has no commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a.
> ...you mean libosmo-abis.
>
>> If you roll-back this commit, does voice re-appear?
> Wow, it actually does! I was pretty sure this would not fix anything. I have
> discussed in detail in OS#1661, and see https://gerrit.osmocom.org/1011 .
>
>
> A pressing issue which you seemingly ignored is that your osmo-bts commit
> 654175f33bd412671e3ef8cdd65c0689d10f278c breaks voice on SysmoBTS. Could you
> grab a sysmoBTS and verify+fix it soon? Otherwise revert.
>
> ~Neels
>

-- 
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  6 18:20:03 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 6 Oct 2016 20:20:03 +0200
Subject: problems compiling for sysmobts
In-Reply-To: <bf8fd8b1-878a-32a5-2aab-23e82f5cfb97@sysmocom.de>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
 <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
 <20161006140146.GC8015@my.box>
 <bf8fd8b1-878a-32a5-2aab-23e82f5cfb97@sysmocom.de>
Message-ID: <20161006182003.GD22552@my.box>

On Thu, Oct 06, 2016 at 04:09:18PM +0200, Max wrote:
> Hi.
> 
> I have not ignored anything, I've pointed to commit which I suspect
> could have broken voice (as you rightfully pointed out it's in
> libosmo-abis). Could you clarify if reverting this commit in
> libosmo-abis fixes the voice for sysmobts master? Or in addition to
> reverting c77c2a6aa13accbc558888ab788d1148eb9aeb1a in libosmo-abis I've
> got to checkout some later commit in sysmobts?
> 
> If reverting commit in libosmo-abis indeed fixes voice for sysmobts sdk
> 1.5.4 than please send patch for review (add me as reviewer).
> 
> Right now I'm working on DTX rewrite using FSM which might fix sysmobts
> if it's indeed broken (after fixing libosmo-abis).

These are two distinct issues. The one with no voice at all happens on 1.5.4
and is fixed by gerrit #1011.

The other issue is that SysmoBTS voice is hickuped/distorted starting from your
first DTX commit 654175f33bd412671e3ef8cdd65c0689d10f278c on osmo-bts. (This on
both 1.5.3 and 1.5.4, with and without #1011 applied.)

So please grab a SysmoBTS and test DTX against it :)

~Neels

-- 
- 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/20161006/03f88948/attachment.bin>

From laforge at gnumonks.org  Fri Oct  7 18:10:29 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 7 Oct 2016 20:10:29 +0200
Subject: reverting commits / no voice / Re: problems compiling for sysmobts
In-Reply-To: <20161006182003.GD22552@my.box>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
 <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
 <20161006140146.GC8015@my.box>
 <bf8fd8b1-878a-32a5-2aab-23e82f5cfb97@sysmocom.de>
 <20161006182003.GD22552@my.box>
Message-ID: <20161007181029.vctvecwxzxdk3kmk@nataraja>

On Thu, Oct 06, 2016 at 08:20:03PM +0200, Neels Hofmeyr wrote:
> > I have not ignored anything, I've pointed to commit which I suspect
> > could have broken voice (as you rightfully pointed out it's in
> > libosmo-abis). Could you clarify if reverting this commit in
> > libosmo-abis fixes the voice for sysmobts master? Or in addition to
> > reverting c77c2a6aa13accbc558888ab788d1148eb9aeb1a in libosmo-abis I've
> > got to checkout some later commit in sysmobts?
> > 
> > If reverting commit in libosmo-abis indeed fixes voice for sysmobts sdk
> > 1.5.4 than please send patch for review (add me as reviewer).
> 
> These are two distinct issues. The one with no voice at all happens on 1.5.4
> and is fixed by gerrit #1011.

Can you please clarify.  When you say "on 1.5.4" you mean that you used
a SDK/toolchain from 201310-nightly. However, did you also run a
201310-nightly filesystem on the BTS at that time?

The recent changes in libosmo-abis require the use of a more recent
libortp.  The filesystem + SDK of 201310-nightly contains that later
version and should thus be expected to work.

What is of course not supposed to work is a filesystem (including ortp
binary) of 201310-stable or -testing with a osmo-bts binary built on a
SDK/toolchain from 201310-nightly.

Please confirm that this is not the case in your testing.

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  Sun Oct  9 22:01:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 10 Oct 2016 00:01:01 +0200
Subject: reverting commits / no voice / Re: problems compiling for sysmobts
In-Reply-To: <20161007181029.vctvecwxzxdk3kmk@nataraja>
References: <20161005014302.GF3784@my.box> <20161005024903.GG3784@my.box>
 <2fe766c5-2c22-ab57-e303-959a4482f2d9@sysmocom.de>
 <20161006140146.GC8015@my.box>
 <bf8fd8b1-878a-32a5-2aab-23e82f5cfb97@sysmocom.de>
 <20161006182003.GD22552@my.box>
 <20161007181029.vctvecwxzxdk3kmk@nataraja>
Message-ID: <20161009220101.GA2661@my.box>

On Fri, Oct 07, 2016 at 08:10:29PM +0200, Harald Welte wrote:
> Can you please clarify.  When you say "on 1.5.4" you mean that you used
> a SDK/toolchain from 201310-nightly. However, did you also run a
> 201310-nightly filesystem on the BTS at that time?

So, what I usually do is

osmo*  ---make-install-->  SDK-sysroot  ---copy-->  bts:~/neels/lib
bts: export LD_LIBRARY_PATH=~/neels/lib ; ~/neels/bin/osmo-bts

In words, compile the entire osmo toolchain that I use from libosmocore up,
installing *into* my computer's SDK's sysroot, and when all is built I copy the
binaries I want to test as well as the entire usr/lib/ from the SDK over to the
BTS ($SYSMO_SDK/sysroots/armv5te-poky-linux-gnueabi/usr/lib). In the
environment to run those built binaries on the BTS, I point LD_LIBRARY_PATH at
the location where I copied the SDK's libraries. This should run the binaries
in the library scenario as intended by the SDK, also including the osmo libs
built in the same cycle, not actually using the older libs in bts:/usr/lib.

That's a quick way around re-installing the BTS from scratch. That should be
fine, right? Should I rather overwrite the entire root fs?

Thanks,

~Neels

-- 
- 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/20161010/2516c673/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 10 00:38:03 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 10 Oct 2016 02:38:03 +0200
Subject: openbsc: rate ctr segfault in master
Message-ID: <20161010003803.GA22680@my.box>

Hi lynxis,

I have reverted your recent commit 38e9ea3 (see below): it introduces a
reproducable segfault in openbsc, because msg->trx is not actually set/used in
the openbsc code paths (it seems only osmo-bts uses msg->trx).

FYI, struct msgb is used very generically in osmocom, and it's dangerous to
assume that any of its members are valid or consistent with other callers,
without fully understanding and testing the surrounding code paths.


commit 38e9ea3f7f385c6660c5958970af5c71adc1682b
Author: Alexander Couzens <lynxis at fe80.eu>
Date:   Tue Aug 23 06:27:19 2016 +0200

    bsc: count the usage of codec by setting the lchan active
    
    we count the codec when the channel was successful setted up
    
    Change-Id: Ifc8a406a11dce16b9e7f3310841e470545550a2c


Backtrace:

20161010011516712 DCC <0001> ../../../src/libmsc/transaction.c:71 subscr=0x813b20, net=0x7e0150
20161010011516712 DPAG <0007> ../../../src/libbsc/paging.c:291 Start paging of subscriber 49 on bts 0.
20161010011517034 DRLL <0000> ../../../src/libbsc/abis_rsl.c:1959 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
20161010011517034 DRSL <0004> ../../../src/libbsc/abis_rsl.c:2176 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3

Program received signal SIGSEGV, Segmentation fault.
count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
104				rate_ctr_inc(&bts->network->bsc_ctrs->ctr[BSC_CTR_CODEC_V1_FR]);
(gdb) bt
#0  count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
#1  0x0000000000425661 in abis_rsl_rx_dchan (msg=<optimized out>) at ../../../src/libbsc/abis_rsl.c:1516
#2  abis_rsl_rcvmsg (msg=0x8143f0) at ../../../src/libbsc/abis_rsl.c:2611
#3  0x00007ffff71420d0 in handle_ts1_read (bfd=<optimized out>) at ../../src/input/ipaccess.c:271
#4  ipaccess_fd_cb (bfd=0x815af8, what=1) at ../../src/input/ipaccess.c:386
#5  0x00007ffff7779b62 in osmo_fd_disp_fds (_eset=0x7fffffffe590, _wset=0x7fffffffe510, _rset=0x7fffffffe490) at ../../src/select.c:149
#6  osmo_select_main (polling=polling at entry=0) at ../../src/select.c:189
#7  0x0000000000406fac in main (argc=<optimized out>, argv=0x7fffffffe738) at ../../../src/osmo-nitb/bsc_hack.c:385
(gdb) 


Hope you can find a different way to count codec uses :)

~Neels

-- 
- 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/20161010/088775a2/attachment.bin>

From holger at freyther.de  Mon Oct 10 11:37:49 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 10 Oct 2016 13:37:49 +0200
Subject: openbsc: rate ctr segfault in master
In-Reply-To: <20161010003803.GA22680@my.box>
References: <20161010003803.GA22680@my.box>
Message-ID: <9E8A509A-E0D8-4818-98A1-62D64240F551@freyther.de>


> On 10 Oct 2016, at 02:38, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> Hi lynxis,


> #1  0x0000000000425661 in abis_rsl_rx_dchan (msg=<optimized out>) at ../../../src/libbsc/abis_rsl.c:1516
> #2  abis_rsl_rcvmsg (msg=0x8143f0) at ../../../src/libbsc/abis_rsl.c:2611

lchan->trx->ts is to be preferred over msg->bts :)




From msuraev at sysmocom.de  Tue Oct 11 09:04:43 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 11 Oct 2016 11:04:43 +0200
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=bZmoDX+C1DrV_Utt+4pmdUeGzNLzpX9n9j=s9NDj_Org@mail.gmail.com>
References: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>
 <CAPEnp=Ym+RvE_LSdDf1V97NvSgGOTQZaoE1hwZ36x67WWhW9TA@mail.gmail.com>
 <CAATyM+a6n2xBT9MVtUQG7DcrQGi=7k9TbrN8cqeu56Nz9ygQkw@mail.gmail.com>
 <CAHL+j081uWBUhuC1roOV45FpM=n3f=+ha_YryxjMCk5SFxvbqA@mail.gmail.com>
 <CAPEnp=ZWLo__VLMd7faf8TqK5F9Xzfnujmczr2dRD5kb=PcOuA@mail.gmail.com>
 <8C00661C-EE43-4107-8FBB-FD86EB010CA2@gnumonks.org>
 <CAPEnp=bZmoDX+C1DrV_Utt+4pmdUeGzNLzpX9n9j=s9NDj_Org@mail.gmail.com>
Message-ID: <27356545-cac4-43e2-7e8f-e722e7a323db@sysmocom.de>

Hi.

I think the puncturing code should be part of the library (otherwise
every user will have to reimplement the same thing again and again).
Unfortunately I could not find any tests for the code in question so the
only way to test it is by:

- add code with puncturing to the library

- replace manual puncturing with generic call

- run gprs with fixes CS* to make sure necessary code is triggered

- verify that it works as before


On 10/02/2016 09:11 AM, Vadim Yanitskiy wrote:
> Hi Harald,
>
> > Why the code differs, I don't know. Maybe it was
> > never completed in conv_gen?
>
> It seems, I found the answer. If you look closer at
> gsm0503_coding.c/gsm0503_pdtch_encode(), you will see:
>
> // Around line 1300, CS-2 encoding
> // ...
>
> osmo_pbit2ubit_ext(conv, 3, l2_data, 0, 271, 1);
> usf = l2_data[0] & 0x7;
>
> osmo_crc16gen_set_bits(&gsm0503_cs234_crc16, conv + 3,
>     271, conv + 3 + 271);
>
> memcpy(conv, gsm0503_usf2six[usf], 6);
>
> osmo_conv_encode(&gsm0503_cs2, conv, cB);
>
> //
> for (i = 0, j = 0; i < 588; i++)
>     if (!gsm0503_puncture_cs2[i])
>         cB[j++] = cB[i];
>
> hl_hn = gsm0503_pdtch_hl_hn_ubit[1];
>
> // ...
>
> So, as I understand, this code applies puncture itself.
> But in our case, the osmo_conv_encode() applies puncture
> too, from the gsm0503_cs2 convolutional code definition.
> The same things happens in the gsm0503_pdtch_decode().
>
> There are two possible ways to go in my mind:
>
> 1) The simplest way is to merely remove puncture from
>    both gsm0503_cs2 and gsm0503_cs3 definitions, but
>    it may break some code, which already uses current
>    variant.
> 2) Change exactly the gsm0503_coding.c to use puncture
>    from shared convolutional code definitions. For me,
>    this way is prefered, but I don't know how to change
>    the code yet.
>
> Any opinions?
> Does any project use the convolutional code definitions
> from 'utils/conv_gen.py'?
>
>
> With best regards,
> Vadim Yanitskiy.
>
> 2016-09-29 21:40 GMT+07:00 Harald Welte <laforge at gnumonks.org
> <mailto:laforge at gnumonks.org>>:
>
>     From my memory:
>
>     * CS1 is rate 1/2 conv code with no puncturing.
>     * CS2+3 apply different puncturing amounts on that conv code
>     * CS4 has no error correction (=100% puncturing)
>
>     Why the code differs, I don't know. Maybe it was never completed
>     in conv_gen?
>
>     --
>     Sent from a mobile device. Please excuse my brevity.
>
>

-- 
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  Wed Oct 12 10:00:38 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 12 Oct 2016 12:00:38 +0200
Subject: Review of conv_gen changes
Message-ID: <20161012100038.iepgfpyx4l6qaco4@nataraja>

Hi Sylvian,

I was hoping that you could review the conv_gen.py and related changes
that Vadim has been working on. I don't feel familiar enough with the
code (and not morally authorized to merge such significant canges) to
your code.

The code is at https://gerrit.osmocom.org/#/c/828/5 as well as related
changes like https://gerrit.osmocom.org/#/c/829/4

Thanks!

-- 
- 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  Wed Oct 12 11:37:31 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 12 Oct 2016 13:37:31 +0200
Subject: [MERGED] libosmo-abis[master]: Resync RTP session in case of
 timestamp jump
In-Reply-To: <20161012092602.663561E414@lists.osmocom.org>
References: <gerrit.1475850537542.Iae5da832218dbd1ede7a9451102074f2a5eb66df@gerrit.osmocom.org>
 <20161012092602.663561E414@lists.osmocom.org>
Message-ID: <20161012113731.GA1481@my.box>

In below patch (already merged) there's apparently only a LOGP tweak.
Looks like something is missing there and Harald didn't spot it?
It can't possibly fix OS#1803, can it?

~Neels

On Wed, Oct 12, 2016 at 09:26:01AM +0000, Harald Welte wrote:
> Harald Welte has submitted this change and it was merged.
> 
> Change subject: Resync RTP session in case of timestamp jump
> ......................................................................
> 
> 
> Resync RTP session in case of timestamp jump
> 
> This will prevent the timestamp jump to occur between each call for DTX
> if something goes wrong. It's handy as oRTP does not manage well
> timestamp jump if it is not resynced.
> 
> Fixes: OS#1803
> Change-Id: Iae5da832218dbd1ede7a9451102074f2a5eb66df
> ---
> M src/trau/osmo_ortp.c
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Approvals:
>   Harald Welte: Looks good to me, approved
>   Jenkins Builder: Verified
> 
> 
> 
> diff --git a/src/trau/osmo_ortp.c b/src/trau/osmo_ortp.c
> index 6ce70d2..e3c6234 100644
> --- a/src/trau/osmo_ortp.c
> +++ b/src/trau/osmo_ortp.c
> @@ -139,7 +139,8 @@
>  	uint32_t ts = rtp_session_get_current_recv_ts(rs);
>  
>  	LOGP(DLMIB, LOGL_NOTICE,
> -	     "osmo-ortp(%d): timestamp_jump, new TS %d\n", port, ts);
> +	     "osmo-ortp(%d): timestamp_jump, new TS %d, resyncing\n", port, ts);
> +	rtp_session_resync(rs);
>  }
>  
>  
> 
> -- 
> To view, visit https://gerrit.osmocom.org/1028
> To unsubscribe, visit https://gerrit.osmocom.org/settings
> 
> Gerrit-MessageType: merged
> Gerrit-Change-Id: Iae5da832218dbd1ede7a9451102074f2a5eb66df
> Gerrit-PatchSet: 4
> Gerrit-Project: libosmo-abis
> Gerrit-Branch: master
> Gerrit-Owner: Max <msuraev at sysmocom.de>
> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
> Gerrit-Reviewer: Jenkins Builder

-- 
- 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/20161012/b8298c17/attachment.bin>

From msuraev at sysmocom.de  Wed Oct 12 11:44:25 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 12 Oct 2016 13:44:25 +0200
Subject: [MERGED] libosmo-abis[master]: Resync RTP session in case of
 timestamp jump
In-Reply-To: <20161012113731.GA1481@my.box>
References: <gerrit.1475850537542.Iae5da832218dbd1ede7a9451102074f2a5eb66df@gerrit.osmocom.org>
 <20161012092602.663561E414@lists.osmocom.org> <20161012113731.GA1481@my.box>
Message-ID: <f382eb30-ef02-2160-38d4-7fc94d2cedb8@sysmocom.de>

No it also have a call to rtp_session_resync(rs); - look at the diff.
And it does not fix 1803 alone, only in combination with other fixes.


On 10/12/2016 01:37 PM, Neels Hofmeyr wrote:
> In below patch (already merged) there's apparently only a LOGP tweak.
> Looks like something is missing there and Harald didn't spot it?
> It can't possibly fix OS#1803, can it?
>
> ~Neels
>
> On Wed, Oct 12, 2016 at 09:26:01AM +0000, Harald Welte wrote:
>> Harald Welte has submitted this change and it was merged.
>>
>> Change subject: Resync RTP session in case of timestamp jump
>> ......................................................................
>>
>>
>> Resync RTP session in case of timestamp jump
>>
>> This will prevent the timestamp jump to occur between each call for DTX
>> if something goes wrong. It's handy as oRTP does not manage well
>> timestamp jump if it is not resynced.
>>
>> Fixes: OS#1803
>> Change-Id: Iae5da832218dbd1ede7a9451102074f2a5eb66df
>> ---
>> M src/trau/osmo_ortp.c
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> Approvals:
>>   Harald Welte: Looks good to me, approved
>>   Jenkins Builder: Verified
>>
>>
>>
>> diff --git a/src/trau/osmo_ortp.c b/src/trau/osmo_ortp.c
>> index 6ce70d2..e3c6234 100644
>> --- a/src/trau/osmo_ortp.c
>> +++ b/src/trau/osmo_ortp.c
>> @@ -139,7 +139,8 @@
>>  	uint32_t ts = rtp_session_get_current_recv_ts(rs);
>>  
>>  	LOGP(DLMIB, LOGL_NOTICE,
>> -	     "osmo-ortp(%d): timestamp_jump, new TS %d\n", port, ts);
>> +	     "osmo-ortp(%d): timestamp_jump, new TS %d, resyncing\n", port, ts);
>> +	rtp_session_resync(rs);
>>  }
>>  
>>  
>>
>> -- 
>> To view, visit https://gerrit.osmocom.org/1028
>> To unsubscribe, visit https://gerrit.osmocom.org/settings
>>
>> Gerrit-MessageType: merged
>> Gerrit-Change-Id: Iae5da832218dbd1ede7a9451102074f2a5eb66df
>> Gerrit-PatchSet: 4
>> Gerrit-Project: libosmo-abis
>> Gerrit-Branch: master
>> Gerrit-Owner: Max <msuraev at sysmocom.de>
>> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
>> Gerrit-Reviewer: Jenkins Builder

-- 
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 12 14:46:04 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 12 Oct 2016 16:46:04 +0200
Subject: move to gerrit
Message-ID: <20161012144604.GB1481@my.box>

Hi all,

opinions please: I would move patch submission for the following osmocom
repositories to gerrit:

osmo-gsm-manuals
asn1c
libasn1c
osmo-python-tests
osmo-trx (TT already agreed)

Let me know if any other come to mind. Possibly *all* projects seen at
git.osmocom.org?

Thanks,
~Neels

-- 
- 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/20161012/e6ac3f22/attachment.bin>

From axilirator at gmail.com  Wed Oct 12 17:51:19 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 12 Oct 2016 23:51:19 +0600
Subject: OsmoBTS -> libosmogsm code migration
Message-ID: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>

Hi Max,

> Unfortunately I could not find any tests for the code in
> question so the only way to test it is by:

I uploaded tests recently. You can find them here:
https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c

> I think the puncturing code should be part of the library (otherwise
> every user will have to reimplement the same thing again and again).

I am agree with you. We recently discussed this question with Tom Tsou.
He said, that there was some performance related reasons to perform
puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().


With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161012/9f686832/attachment.htm>

From msuraev at sysmocom.de  Wed Oct 12 17:58:28 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 12 Oct 2016 19:58:28 +0200
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
Message-ID: <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>

Is there some microbenchmark available? Perhaps we can use it to improve
generated code?


On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
> Hi Max,
>
> > Unfortunately I could not find any tests for the code in
> > question so the only way to test it is by:
>
> I uploaded tests recently. You can find them here:
> https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
>
> > I think the puncturing code should be part of the library (otherwise
> > every user will have to reimplement the same thing again and again).
>
> I am agree with you. We recently discussed this question with Tom Tsou.
> He said, that there was some performance related reasons to perform
> puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
>
>
> With best regards,
> Vadim Yanitskiy.

-- 
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 axilirator at gmail.com  Wed Oct 12 18:10:33 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 13 Oct 2016 00:10:33 +0600
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
 <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
Message-ID: <CAPEnp=Yt4t1d4y_LJE74A5yyA8MPdOKrtsUEpOWuR=5BJMQHNQ@mail.gmail.com>

I don't know. Maybe Tom has one?
Otherwise I can try to write myself.

Tom Tsou wrote:

> There was a discussion many years ago about puncturing
> inside or outside of the convolutional coder loops. I preferred
> separating puncturing and convolutional coding because of efficiency.
> Using discrete implementations allows faster implementations.


With best regards,
Vadim Yanitskiy.

2016-10-13 0:58 GMT+07:00 Max <msuraev at sysmocom.de>:

> Is there some microbenchmark available? Perhaps we can use it to improve
> generated code?
>
>
> On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
> > Hi Max,
> >
> > > Unfortunately I could not find any tests for the code in
> > > question so the only way to test it is by:
> >
> > I uploaded tests recently. You can find them here:
> > https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
> >
> > > I think the puncturing code should be part of the library (otherwise
> > > every user will have to reimplement the same thing again and again).
> >
> > I am agree with you. We recently discussed this question with Tom Tsou.
> > He said, that there was some performance related reasons to perform
> > puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
> >
> >
> > With best regards,
> > Vadim Yanitskiy.
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161013/ee206304/attachment.htm>

From tom at tsou.cc  Wed Oct 12 18:47:16 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 12 Oct 2016 11:47:16 -0700
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
Message-ID: <CAATyM+bqQ8c9rgqAHt=4qMySovW2nMN8meQmP_FhJDWKLYGx=g@mail.gmail.com>

On Wed, Oct 12, 2016 at 10:51 AM, Vadim Yanitskiy <axilirator at gmail.com> wrote:
>> I think the puncturing code should be part of the library (otherwise
>> every user will have to reimplement the same thing again and again).
>
> I am agree with you. We recently discussed this question with Tom Tsou.
> He said, that there was some performance related reasons to perform
> puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().

>From an API standpoint, it makes no difference and makes sense to move
the puncturing into the library. Regarding the implementation, there
is a significant difference.

Puncturing and convolutional coding are inherently discrete steps. It
is possible, as in the library, to reconstruct the non-punctured bit
vector while feeding into the Viterbi at same time, but the downside
of this approach is reduced optimization (or potential optimization).

The reason is that the Viterbi always runs at the full non-punctured
rate and can be implemented with well known trellis coding
optimizations. Puncturing is a completely separate algorithm from the
Viterbi, and integrating them together provides no performance benefit
at best and degradation at worst.

That said, the one advantage to puncturing inside the Viterbi is for
handling continuous non-fixed length codes. But, those codes are not
used by GSM or 3GPP in general, so they are not relevant here.

In summary, my concern is about the implementation and not the API.
Perhaps we could pull the puncturing into the library as Max suggests.
Then, separately, consider performance changes to the internal
puncturing and Viterbi implementations.

  -TT


From tom at tsou.cc  Wed Oct 12 18:54:50 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 12 Oct 2016 11:54:50 -0700
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
 <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
Message-ID: <CAATyM+YjM1EsSY8t9HBbYrzyVRcSjGnZB3GTxwB_bUHxwWFNwQ@mail.gmail.com>

On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev at sysmocom.de> wrote:
> Is there some microbenchmark available? Perhaps we can use it to improve
> generated code?

Potential Viterbi optimization using SIMD methods is substantial as I
demonstrated many years ago. The implementation does require
separation of puncturing and Viterbi. Unfortunately, the has code
experienced code rot since then. Admittedly, I accept much of that
blame.

=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length  : ret = 140  exp = 140 -> OK
[.] Output length : ret = 448  exp = 448 -> OK

[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718

http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html

  -TT


From alexander.chemeris at gmail.com  Wed Oct 12 19:04:09 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Wed, 12 Oct 2016 22:04:09 +0300
Subject: move to gerrit
In-Reply-To: <20161012144604.GB1481@my.box>
References: <20161012144604.GB1481@my.box>
Message-ID: <CABmJbFVsUWoRHTAqbbBN-R1+QYBzSvuGBebjD503Gks=Y8u0hw@mail.gmail.com>

I'm not against using Gerrit for osmo-trx. Might be a good chance for me to
finally start using it more actively.

I don't contribute to other projects in question, so refer to others.

Please excuse typos. Written with a touchscreen keyboard.

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

On Oct 12, 2016 17:46, "Neels Hofmeyr" <nhofmeyr at sysmocom.de> wrote:

> Hi all,
>
> opinions please: I would move patch submission for the following osmocom
> repositories to gerrit:
>
> osmo-gsm-manuals
> asn1c
> libasn1c
> osmo-python-tests
> osmo-trx (TT already agreed)
>
> Let me know if any other come to mind. Possibly *all* projects seen at
> git.osmocom.org?
>
> Thanks,
> ~Neels
>
> --
> - 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/20161012/d2021f2d/attachment.htm>

From tom at tsou.cc  Wed Oct 12 19:07:26 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 12 Oct 2016 12:07:26 -0700
Subject: move to gerrit
In-Reply-To: <CABmJbFVsUWoRHTAqbbBN-R1+QYBzSvuGBebjD503Gks=Y8u0hw@mail.gmail.com>
References: <20161012144604.GB1481@my.box>
 <CABmJbFVsUWoRHTAqbbBN-R1+QYBzSvuGBebjD503Gks=Y8u0hw@mail.gmail.com>
Message-ID: <CAATyM+apcG3mtPr8dOXbHSOg9aq0SmqLvRkSjanYamBGiUhFvw@mail.gmail.com>

On Wed, Oct 12, 2016 at 12:04 PM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> I'm not against using Gerrit for osmo-trx. Might be a good chance for me to
> finally start using it more actively.

There is little reason not to use Gerrit for osmo-trx since that is
the adopted approach for most Osmocom projects. osmo-trx should not be
an exception.

  -TT


From msuraev at sysmocom.de  Thu Oct 13 11:00:11 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 13 Oct 2016 13:00:11 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+aAq7qAP3OhMf14_7o7FkmrB9BCtKEp-UCov7J-yf+s=w@mail.gmail.com>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <aab35bd4-863b-adce-5ac1-d3594d62b77b@sysmocom.de>
 <CAATyM+ZF4sc+nOOhse7f-nhDK_19vGVXd5Xq1XESvkEqDO9Qtw@mail.gmail.com>
 <1000115700.9468029.1470852494820.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CAATyM+aAq7qAP3OhMf14_7o7FkmrB9BCtKEp-UCov7J-yf+s=w@mail.gmail.com>
Message-ID: <7a61dd15-1e1a-158a-8f9d-aab2a2461b77@sysmocom.de>

What's the situation with UHD version support now?

I've tried running "./Transceiver52M/osmo-trx -m -c 2 -e -l INFO -g"
from recent osmo-trx master ang got following errors with different UHS
version:


linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.000.000-release

-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
INFO 3032143616 12:57:24.6 UHDDevice.cpp:786:open: Using discovered UHD
device type=b200,name=MyB210,serial=30AC26A,product=B210
ALERT 3032143616 12:57:25.8 UHDDevice.cpp:790:open: UHD make failed, device
ALERT 3032143616 12:57:25.8 UHDDevice.cpp:790:open: UHD make failed, device
ALERT 3032143616 12:57:25.8 osmo-trx.cpp:530:main: Failed to create
radio device

ALERT 3032143616 12:57:25.8 osmo-trx.cpp:530:main: Failed to create
radio device
Shutting down transceiver...


linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.004-0-unknown

INFO 3036346112 12:51:39.9 UHDDevice.cpp:786:open: Using discovered UHD
device type=b200,name=MyB210,serial=30AC26A,product=B210
-- Operating over USB 2.         
-- Initialize CODEC control...   
-- Initialize Radio control...   
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz
-- Actually got clock rate 32.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
INFO 3036346112 12:51:43.3 UHDDevice.cpp:743:parse_dev_type: Using USRP1
type transmit window for B-Series Device B210
-- Asking for clock rate 3.200000 MHz
                                 
UHD Warning:                     
    The requested master_clock_rate 3.200000 MHz exceeds bounds imposed
by UHD.
    The master_clock_rate has been forced to 5.000000 MHz.
-- Actually got clock rate 5.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:546:set_master_clk: Failed to
set master clock rate
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:546:set_master_clk: Failed to
set master clock rate
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:547:set_master_clk: Requested
clock rate 3.2e+06
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:547:set_master_clk: Requested
clock rate 3.2e+06
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:548:set_master_clk: Actual
clock rate 5e+06
ALERT 3036346112 12:51:45.0 UHDDevice.cpp:548:set_master_clk: Actual
clock rate 5e+06
ALERT 3036346112 12:51:45.0 osmo-trx.cpp:530:main: Failed to create
radio device
                                 
ALERT 3036346112 12:51:45.0 osmo-trx.cpp:530:main: Failed to create
radio device
Shutting down transceiver...     


On 08/11/2016 04:14 AM, Tom Tsou wrote:
> On Wed, Aug 10, 2016 at 11:08 AM, Sipos Csaba
> <sipos.csaba at kvk.uni-obuda.hu> wrote:
>>> There is a UHD version requirement to clock the B200/B210 below 5 MHz
>> Can you tell which version it is?
>>
>> I am using 3.9.4
> Unfortunately, the requirement turns out to be master. I'm testing a
> workaround for prior UHD versions.
>
>   -TT

-- 
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 13 11:36:40 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 13 Oct 2016 13:36:40 +0200
Subject: [MERGED] libosmo-abis[master]: Resync RTP session in case of
 timestamp jump
In-Reply-To: <f382eb30-ef02-2160-38d4-7fc94d2cedb8@sysmocom.de>
References: <gerrit.1475850537542.Iae5da832218dbd1ede7a9451102074f2a5eb66df@gerrit.osmocom.org>
 <20161012092602.663561E414@lists.osmocom.org>
 <20161012113731.GA1481@my.box>
 <f382eb30-ef02-2160-38d4-7fc94d2cedb8@sysmocom.de>
Message-ID: <20161013113640.GA1639@my.box>

On Wed, Oct 12, 2016 at 01:44:25PM +0200, Max wrote:
> No it also have a call to rtp_session_resync(rs); - look at the diff.
> >> -	     "osmo-ortp(%d): timestamp_jump, new TS %d\n", port, ts);
> >> +	     "osmo-ortp(%d): timestamp_jump, new TS %d, resyncing\n", port, ts);
> >> +	rtp_session_resync(rs);

oh indeed, I overlooked that little line of code, sorry for the noise.

~Neels

-------------- 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/20161013/0b901ec8/attachment.bin>

From msuraev at sysmocom.de  Thu Oct 13 11:43:25 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 13 Oct 2016 13:43:25 +0200
Subject: osmo-trx and gpsdo
Message-ID: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>

Hi.

While trying to make osmo-trx work in multichannel configuration I've
found following:
- running "./Transceiver52M/osmo-trx -m -c 2 -l INFO" works but
- running "./Transceiver52M/osmo-trx -m -c 2 -l INFO -g" gives following:
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.000.000-release
                                  
opening configuration table from path :memory:
Config Settings                   
   Log Level............... INFO  
   Device args.............       
   TRX Base Port........... 5700  
   TRX Address............. 127.0.0.1
   Channels................ 2     
   Tx Samples-per-Symbol... 4     
   Rx Samples-per-Symbol... 4     
   EDGE support............ Disabled
   Reference............... GPS   
   C0 Filler Table......... Disabled
   Multi-Carrier........... Enabled
   Diversity............... Disabled
   Tuning offset........... 0     
   RSSI to dBm offset...... 0     
   Swap channels........... 0     
                                  
INFO 3032180480 13:36:38.4 UHDDevice.cpp:786:open: Using discovered UHD
device type=b200,name=MyB210,serial=30AC26A,product=B210
-- Detected Device: B210          
-- Operating over USB 2.          
-- Initialize CODEC control...    
-- Initialize Radio control...    
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 16.000000 MHz...
-- Actually got clock rate 16.000000 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
INFO 3032180480 13:36:41.6 UHDDevice.cpp:743:parse_dev_type: Using USRP1
type transmit window for B-Series Device B210
terminate called after throwing an instance of 'uhd::key_error'
  what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo
Aborted (core dumped)             

The tests were performed with usrp B210 and rather recent uhd (see
above). Is this some know error/hw incompatibility?

-- 
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  Thu Oct 13 14:34:54 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 13 Oct 2016 16:34:54 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+bJ61oUQPo2Fe=NK67uCOvZXLhp4YgcBzyYpGcMTaaLAA@mail.gmail.com>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <fb6a2461-2567-9aac-6868-1abd6554bb17@sysmocom.de>
 <CAATyM+awARAERvFhjc0KYkCdaJ=oBj+Qk6arpdWwHrAWv8OnjA@mail.gmail.com>
 <b753ccad-39ed-7896-5b93-b4a2ea56700b@sysmocom.de>
 <CAATyM+bJ61oUQPo2Fe=NK67uCOvZXLhp4YgcBzyYpGcMTaaLAA@mail.gmail.com>
Message-ID: <e71cfe66-a3df-bb5a-3654-d086cb6969bb@sysmocom.de>

Hi.

After updating uhd to UHD_003.010.000.000-release I got it partially
working. It's summarized in https://projects.osmocom.org/issues/1648

If I understood correctly there are 2 possibilities for multi-trx setup
with osmo-trx: multiplexed and non-multiplexed. The command to run
osmo-bts-trx is the same in both cases: you've got to specify number of
trx like in "./src/osmo-bts-trx/osmo-bts-trx -c
~/.config/osmocom/osmo-bts-mtrx.cfg -t 2". From osmo-trx, the difference is:

non-multiplexed: ./Transceiver52M/osmo-trx -c 2 -l INFO

multiplexed: ./Transceiver52M/osmo-trx -m -c 2 -l INFO

The question is - is there any difference between multiplexed and
non-multiplexed mode for osmo-bts-trx config file? I've got multiplexed
mode working with following setup:

...

phy 0
 instance 0
 instance 1
...

 trx 0
  phy 0 instance 0
 trx 1
  phy 0 instance 1
...

Should it look differently for non-multiplexed mode? Are there some
other command-line options or config files adjustments missing to make
non-multiplexed mode working? Did I got the overall setup right?


On 08/12/2016 09:05 PM, Tom Tsou wrote:
> On Thu, Aug 11, 2016 at 2:50 AM, Max <msuraev at sysmocom.de> wrote:
>> On 08/10/2016 07:35 PM, Tom Tsou wrote:
>>> The 'multi-carrier' approach multiplexes up to 3 ARFCN channels onto a
>>> single physical RF channel (side A) on the B210. Channel spacing is
>>> fixed at 800 kHz, or 4 ARFCN channels. ARFCN settings from OpenBSC
>>> must match accordingly. The '-m' option enables this configuration.
>> Could you give an example of necessary openbsc and osmo-bts
>> configuration for both cases?
> Config files and README are attached. Note that the osmo-trx
> multi-carrier '-m' option requires UHD master. I'm still backporting
> the needed settings.
>
>>> Also note that the above configurations cannot be combined.
>> So I should not run "./Transceiver52M/osmo-trx -c 2 -g -m"?
>> Only "./Transceiver52M/osmo-trx -c 2 -g" or "./Transceiver52M/osmo-trx
>> -g -m"?
>> Or you referring to the incompatibility of configuration of openbsc? Or
>> Osmobts?
> You cannot support, for example, 6 ARFCN operation on B210 using 3 TRX
> on side A and another 3 TRX on side B.
>
> Whether you use '-c 2 -m' or just '-c 2' depends on whether you want
> to feed two ARFCN channels through 1 or 2 PA's respectively.
>
>   -TT

-- 
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 ikostov at sysmocom.de  Thu Oct 13 15:10:03 2016
From: ikostov at sysmocom.de (Ivaylo Kostov)
Date: Thu, 13 Oct 2016 17:10:03 +0200
Subject: [PATCH] Typo in Chapter 14.2
Message-ID: <1476371403-17304-1-git-send-email-ikostov@sysmocom.de>

---
 OsmoNITB/chapters/smpp.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OsmoNITB/chapters/smpp.adoc b/OsmoNITB/chapters/smpp.adoc
index 2557580..91f8c07 100644
--- a/OsmoNITB/chapters/smpp.adoc
+++ b/OsmoNITB/chapters/smpp.adoc
@@ -44,7 +44,7 @@ SMPP (`no smpp-first`).
 
 === ESME configuration
 
-nder the `smpp` vty node, you can add any number of `esme` nodes, one
+Under the `smpp` vty node, you can add any number of `esme` nodes, one
 for each ESME that you wish to configure.
 
 Use the `esme NAME` command (where NAME corresponds to the system-id of
-- 
2.7.4



From laforge at gnumonks.org  Thu Oct 13 16:00:15 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 13 Oct 2016 18:00:15 +0200
Subject: move to gerrit
In-Reply-To: <20161012144604.GB1481@my.box>
References: <20161012144604.GB1481@my.box>
Message-ID: <20161013160015.mghushf3iery3c2w@nataraja>

On Wed, Oct 12, 2016 at 04:46:04PM +0200, Neels Hofmeyr wrote:
> opinions please: I would move patch submission for the following osmocom
> repositories to gerrit:
> 
> osmo-gsm-manuals
> asn1c
> libasn1c
> osmo-python-tests
> osmo-trx (TT already agreed)

fine with me.

> Let me know if any other come to mind. 

it doesn't make much difference as there is very litte to zero activity,
but I would suggest the following others:

openpcd
osmo-sim-auth
sim/hello-stk
sim/sim-tools
cellmgr-ng
libtelnet
mncc-python
osmocom-lcs

> Possibly *all* projects seen at git.osmocom.org?

The develoment communities of the various projects are quite disjunct.
We are a home to everyoune doing FOSS mobile communications related
software, and we don't prescribe what kind of tools the respective
projects use.  So I really don't think it is a good idea to keep
suggesting that they use a certain tool.  Those who do the respective
development work get to say how they do it.

Also, the openbsc at lists.osmocom.org mailing list is not the mailing list
for discussions regarding e.g. the rtl-sdr development, or various other
projects which are housed under the Osmocom umbrella.

We can take the decision for the projects in the cellular infrastructure
area which we maintain, and that includes the list you wrote above.

For anything else, I wouldn't even go as far as to suggest them to use
this.  It's up to the individual sub-projects and their maintainers to
determine what kind of tools they want to use (if any).

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 13 16:02:36 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 13 Oct 2016 18:02:36 +0200
Subject: [PATCH] Typo in Chapter 14.2
In-Reply-To: <1476371403-17304-1-git-send-email-ikostov@sysmocom.de>
References: <1476371403-17304-1-git-send-email-ikostov@sysmocom.de>
Message-ID: <20161013160236.42lgp2f42jooiaow@nataraja>

On Thu, Oct 13, 2016 at 05:10:03PM +0200, Ivaylo Kostov wrote:
> -nder the `smpp` vty node, you can add any number of `esme` nodes, one
> +Under the `smpp` vty node, you can add any number of `esme` nodes, one

Thanks, applied.

-- 
- 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 mardnh at gmx.de  Thu Oct 13 17:10:40 2016
From: mardnh at gmx.de (Martin Hauke)
Date: Thu, 13 Oct 2016 19:10:40 +0200
Subject: [PATCH] mobile/vty_interface.c: Fix typo
Message-ID: <20161013171040.GA15181@gmx.de>

---
 src/host/layer23/src/mobile/vty_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/host/layer23/src/mobile/vty_interface.c b/src/host/layer23/src/mobile/vty_interface.c
index 9a86880..f4d7df1 100644
--- a/src/host/layer23/src/mobile/vty_interface.c
+++ b/src/host/layer23/src/mobile/vty_interface.c
@@ -528,7 +528,7 @@ static int _sim_test_cmd(struct vty *vty, int argc, const char *argv[],
 
 DEFUN(sim_test, sim_test_cmd,
 	"sim testcard MS_NAME [MCC] [MNC] [LAC] [TMSI]",
-	"SIM actions\nAttach bulit in test SIM\nName of MS (see \"show ms\")\n"
+	"SIM actions\nAttach built-in test SIM\nName of MS (see \"show ms\")\n"
 	"Optionally set mobile Country Code of RPLMN\n"
 	"Optionally set mobile Network Code of RPLMN\n"
 	"Optionally set location area code of RPLMN\n"
@@ -539,7 +539,7 @@ DEFUN(sim_test, sim_test_cmd,
 
 DEFUN(sim_test_att, sim_test_att_cmd,
 	"sim testcard MS_NAME MCC MNC LAC TMSI attached",
-	"SIM actions\nAttach bulit in test SIM\nName of MS (see \"show ms\")\n"
+	"SIM actions\nAttach built-in test SIM\nName of MS (see \"show ms\")\n"
 	"Set mobile Country Code of RPLMN\nSet mobile Network Code of RPLMN\n"
 	"Set location area code\nSet current assigned TMSI\n"
 	"Indicate to MM that card is already attached")
@@ -1758,7 +1758,7 @@ DEFUN(cfg_ms_sap, cfg_ms_sap_cmd, "sap-socket PATH",
 
 DEFUN(cfg_ms_sim, cfg_ms_sim_cmd, "sim (none|reader|test|sap)",
 	"Set SIM card to attach when powering on\nAttach no SIM\n"
-	"Attach SIM from reader\nAttach bulit in test SIM\n"
+	"Attach SIM from reader\nAttach built-in test SIM\n"
 	"Attach SIM over SAP interface")
 {
 	struct osmocom_ms *ms = vty->index;
-- 
2.6.6



From tom at tsou.cc  Thu Oct 13 18:02:28 2016
From: tom at tsou.cc (Tom Tsou)
Date: Thu, 13 Oct 2016 11:02:28 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <7a61dd15-1e1a-158a-8f9d-aab2a2461b77@sysmocom.de>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <aab35bd4-863b-adce-5ac1-d3594d62b77b@sysmocom.de>
 <CAATyM+ZF4sc+nOOhse7f-nhDK_19vGVXd5Xq1XESvkEqDO9Qtw@mail.gmail.com>
 <1000115700.9468029.1470852494820.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CAATyM+aAq7qAP3OhMf14_7o7FkmrB9BCtKEp-UCov7J-yf+s=w@mail.gmail.com>
 <7a61dd15-1e1a-158a-8f9d-aab2a2461b77@sysmocom.de>
Message-ID: <CAATyM+bxk0WEV4-zqXAik=5xS_qwbj3DGvkxz6nKRtZMOcbAvA@mail.gmail.com>

On Thu, Oct 13, 2016 at 4:00 AM, Max <msuraev at sysmocom.de> wrote:
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.004-0-unknown
>
...
> INFO 3036346112 12:51:43.3 UHDDevice.cpp:743:parse_dev_type: Using USRP1
> type transmit window for B-Series Device B210
> -- Asking for clock rate 3.200000 MHz
>
> UHD Warning:
>     The requested master_clock_rate 3.200000 MHz exceeds bounds imposed
> by UHD.
>     The master_clock_rate has been forced to 5.000000 MHz.

The 3.2 MHz setting was used to get around a timestamp conversion bug
in UHD, but that's not supported in versions below 3.9.0. I don't like
to keep raising the minimum UHD requirement, but that seems to be the
best choice in the current situation.

  -TT


From tom at tsou.cc  Thu Oct 13 18:16:49 2016
From: tom at tsou.cc (Tom Tsou)
Date: Thu, 13 Oct 2016 11:16:49 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <e71cfe66-a3df-bb5a-3654-d086cb6969bb@sysmocom.de>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <fb6a2461-2567-9aac-6868-1abd6554bb17@sysmocom.de>
 <CAATyM+awARAERvFhjc0KYkCdaJ=oBj+Qk6arpdWwHrAWv8OnjA@mail.gmail.com>
 <b753ccad-39ed-7896-5b93-b4a2ea56700b@sysmocom.de>
 <CAATyM+bJ61oUQPo2Fe=NK67uCOvZXLhp4YgcBzyYpGcMTaaLAA@mail.gmail.com>
 <e71cfe66-a3df-bb5a-3654-d086cb6969bb@sysmocom.de>
Message-ID: <CAATyM+b5NtRzfPrYOFgsmL1+SNVb_dQ5Qd=fOPs0Wj=XugEV0w@mail.gmail.com>

On Thu, Oct 13, 2016 at 7:34 AM, Max <msuraev at sysmocom.de> wrote:
> The question is - is there any difference between multiplexed and
> non-multiplexed mode for osmo-bts-trx config file? I've got multiplexed
> mode working with following setup:
> ...
>
> phy 0
>  instance 0
>  instance 1
> ...
>
>  trx 0
>   phy 0 instance 0
>  trx 1
>   phy 0 instance 1
> ...

I used the same configuration.

> Should it look differently for non-multiplexed mode? Are there some
> other command-line options or config files adjustments missing to make
> non-multiplexed mode working? Did I got the overall setup right?

Multiplexed and non-multiplexed configurations should look the same to
osmo-bts. The main difference will be on ARFCN settings.

Multiplexed (MCBTS) - TRX0 is the primary ARFCN. Channel spacing is
fixed at 4, so TRX1 and TRX2 must be set 4 and 8 ARFCN channels higher
than TRX0 respectively.

Non-multiplexed - ARFCN for each channel can be set within the
limitations of the RF device. This will vary depending on the
particular RF product.

  -TT


From nhofmeyr at sysmocom.de  Thu Oct 13 21:39:17 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 13 Oct 2016 23:39:17 +0200
Subject: bind & connect
Message-ID: <20161013213917.GA19440@my.box>

Hi osmo_sock experts,

I'm currently looking at making the osmo-hnbgw interface addresses
configurable, an I came across a detail. This is not really pressing, but while
I'm at it I might as well cover all of the addresses.

So far I see in osmo-iuh's hnbgw.c the local address osmo-hnbgw uses to accept
Iuh connections from a 3G cell, and the remote addresses of IuCS and IuPS, each
passed to osmo_sock_init():

   3G cell  -------> 1.2.3.4
                     OSMO-HNBGW
                     IuPS-local? -------> 10.9.8.7 OSMO-SGSN


So we tell one socket to listen on local 1.2.3.4 for Iuh.
We tell another to send IuPS to 10.9.8.7.

But how would I tell the IuPS to use a given local interface 1.2.3.5 to contact
the SGSN's address? Would I bind() to a given local IP address and connect() to
the remote one? I must admit that the details are not 100% clear to me. AFAIK
it can be important to set a local IP address and port to send from. So if
there's something I don't understand yet I would appreciate a hint.

Anyway, in osmo_sock_init, I see:

        if ((flags & (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) ==
                     (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) {
                fprintf(stderr, "invalid: both bind and connect flags set:"
                        " %s:%u\n", host, port);
                return -EINVAL;
        }

Should we have another osmo_sock_init that can set up a socket like this code I
found somewhere at sysmocom to define both ends of a connection?

        fd = socket(AF_INET, SOCK_DGRAM, 0);
        if (fd < 0) {
                printf("socket() failed: %s\n", strerror(errno));
                return -1;
        }

        memset(&bindaddr, 0, sizeof(bindaddr));
        bindaddr.sin_family = AF_INET;
        bindaddr.sin_port = htons(lport);
        rc = inet_pton(AF_INET, baddr, &(bindaddr.sin_addr));
        if (rc != 1) {
                printf("inet_pton() failed with %i: %s\n", rc, strerror(errno));
                return -1;
        }

        rc = bind(fd, (struct sockaddr *)&bindaddr, sizeof(bindaddr));
        if (rc < 0) {
                printf("bind() failed: %s\n", strerror(errno));
                return -1;
        }

        memset(&destaddr, 0, sizeof(destaddr));
        destaddr.sin_family = AF_INET;
        destaddr.sin_port = htons(dport);
        rc = inet_pton(AF_INET, dest, &(destaddr.sin_addr));
        if (rc != 1) {
                printf("inet_pton() failed with %i: %s\n", rc, strerror(errno));
                return -1;
        }

        rc = connect(fd, (const struct sockaddr *)&destaddr, sizeof(destaddr));
        if (rc < 0) {
                printf("connect() failed: %s\n", strerror(errno));
                return -1;
        }

        rc = send(fd, buf, len, 0);
        if (rc != len) {
                printf("send() failed\n");
                return -1;
        }


Thanks,

~Neels


-- 
- 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/20161013/5570f016/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Oct 13 21:58:14 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 13 Oct 2016 23:58:14 +0200
Subject: move to gerrit
In-Reply-To: <20161013160015.mghushf3iery3c2w@nataraja>
References: <20161012144604.GB1481@my.box>
 <20161013160015.mghushf3iery3c2w@nataraja>
Message-ID: <20161013215814.GA25775@my.box>

On Thu, Oct 13, 2016 at 06:00:15PM +0200, Harald Welte wrote:
> On Wed, Oct 12, 2016 at 04:46:04PM +0200, Neels Hofmeyr wrote:
> > opinions please: I would move patch submission for the following osmocom
> > repositories to gerrit:
> > 
> > osmo-gsm-manuals
> > asn1c
> > libasn1c
> > osmo-python-tests
> > osmo-trx (TT already agreed)
> 
> fine with me.
> 
> > Let me know if any other come to mind. 
> 
> it doesn't make much difference as there is very litte to zero activity,
> but I would suggest the following others:
> 
> openpcd
> osmo-sim-auth
> sim/hello-stk
> sim/sim-tools
> cellmgr-ng
> libtelnet
> mncc-python
> osmocom-lcs

> The develoment communities of the various projects are quite disjunct.

Yes -- I just lack the bigger picture of what is what. Thanks for the list
above.

> For anything else, I wouldn't even go as far as to suggest them to use
> this.

Yes, whoever wants something can say so herself. :)

So, what projects go with which ML, to notify in the right places...
Actually, all of them on openbsc@, plus osmo-trx also on
umtrx at lists.osmocom.org?

Are these two related to simtrace@ -- because they have 'sim' in the name??
 sim/hello-stk
 sim/sim-tools

~Neels

-------------- 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/20161013/f5e25da9/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Oct 13 22:44:42 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 14 Oct 2016 00:44:42 +0200
Subject: New Defects reported by Coverity Scan for Osmocom
Message-ID: <20161013224442.GB25775@my.box>

On Thu, Oct 13, 2016 at 09:32:21AM -0700, scan-admin at coverity.com wrote:
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan.
> 
> 4 new defect(s) introduced to Osmocom found with Coverity Scan.
> 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 4 of 4 defect(s)
> 
> 
> ** CID 150135:  Null pointer dereferences  (REVERSE_INULL)
> /source-Osmocom/openggsn/ggsn/ggsn.c: 142 in delete_context()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 150135:  Null pointer dereferences  (REVERSE_INULL)
> /source-Osmocom/openggsn/ggsn/ggsn.c: 142 in delete_context()
> 136     int delete_context(struct pdp_t *pdp)
> 137     {
> 138     	DEBUGP(DGGSN, "Deleting PDP context\n");
> 139     	struct ippoolm_t *member = pdp->peer;
> 140     	char v[NAMESIZE];
> 141     	snprintf(v, sizeof(v), "%" PRIu64 ",%s", pdp->imsi, inet_ntoa(member->addr));
> >>>     CID 150135:  Null pointer dereferences  (REVERSE_INULL)
> >>>     Null-checking "pdp->peer" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
> 142     	if (pdp->peer)
> 143     		ippool_freeip(ippool, (struct ippoolm_t *)pdp->peer);
> 144     	else
> 145     		SYS_ERR(DGGSN, LOGL_ERROR, 0, "Peer not defined!");
> 146     
> 147     	if (gtp_kernel_tunnel_del(pdp)) {

This one's for you, Max. (openggsn commit 727417dd28813c697b4820aef9f54f249e30c4b8)

> ** CID 150134:  Null pointer dereferences  (REVERSE_INULL)
> /source-Osmocom/openbsc/openbsc/src/gprs/gprs_sgsn.c: 257 in sgsn_mm_ctx_alloc_iu()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 150134:  Null pointer dereferences  (REVERSE_INULL)
> /source-Osmocom/openbsc/openbsc/src/gprs/gprs_sgsn.c: 257 in sgsn_mm_ctx_alloc_iu()
> 251     	ctx->auth_triplet.key_seq = GSM_KEY_SEQ_INVAL;
> 252     	ctx->ctrg = rate_ctr_group_alloc(ctx, &mmctx_ctrg_desc, 0);
> 253     
> 254     	/* Need to get RAID from IU conn */
> 255     	ctx->ra = ctx->iu.ue_ctx->ra_id;
> 256     

fixed (sysmocom/iu branch).

> >>>     CID 150134:  Null pointer dereferences  (REVERSE_INULL)
> >>>     Null-checking "ctx->iu.ue_ctx" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
> 257     	if (ctx->iu.ue_ctx)
> 258     		ctx->iu.ue_ctx->rab_assign_addr_enc =
> 259     			sgsn->cfg.iu.rab_assign_addr_enc;
> 260     
> 261     	INIT_LLIST_HEAD(&ctx->pdp_list);
> 262     


> 
> ** CID 150133:  Memory - corruptions  (OVERRUN)
> /source-Osmocom/osmo-bts/src/common/msg_utils.c: 121 in dtx_cache_payload()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 150133:  Memory - corruptions  (OVERRUN)
> /source-Osmocom/osmo-bts/src/common/msg_utils.c: 121 in dtx_cache_payload()
> 115     	    copy_len = OSMO_MIN(length + 1, ARRAY_SIZE(lchan->tch.dtx.cache));
> 116     
> 117     	lchan->tch.dtx.len = copy_len + amr;
> 118     	lchan->tch.dtx.fn = fn;
> 119     	lchan->tch.dtx.is_update = update;
> 120     
> >>>     CID 150133:  Memory - corruptions  (OVERRUN)
> >>>     Overrunning buffer pointed to by "&lchan->tch.dtx.cache[amr]" of 20 bytes by passing it to a function which accesses it at byte offset 21 using argument "copy_len" (which evaluates to 20).
> 121     	memcpy(lchan->tch.dtx.cache + amr, l1_payload, copy_len);

@Max, maybe 'copy_len - amr'? In any case there's potentially 'amr' too many
bytes.

> 122     }
> 123     
> 124     /*! \brief Check current state of DTX DL AMR FSM and dispatch necessary events
> 125      *  \param[in] lchan Logical channel on which we check scheduling
> 126      *  \param[in] rtp_pl buffer with RTP data
> 
> ** CID 150132:  Incorrect expression  (BAD_SIZEOF)
> /source-Osmocom/osmo-bts/src/common/msg_utils.c: 262 in dtx_sched_optional()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 150132:  Incorrect expression  (BAD_SIZEOF)
> /source-Osmocom/osmo-bts/src/common/msg_utils.c: 262 in dtx_sched_optional()
> 256     				h1[] = { 14, 16, 18, 20, 66, 68, 70, 72 };
> 257     	if (lchan->tch_mode == GSM48_CMODE_SPEECH_V1) {
> 258     		if (lchan->type == GSM_LCHAN_TCH_F)
> 259     			return fn_chk(f, fn, ARRAY_SIZE(f));
> 260     		else
> 261     			return fn_chk(lchan->nr ? h1 : h0, fn,
> >>>     CID 150132:  Incorrect expression  (BAD_SIZEOF)
> >>>     The expression "sizeof (lchan->nr ? h1 : h0) / sizeof (lchan->nr ? h1 : h0[0])" is suspicious. Note that "lchan->nr ? h1 : h0" is a pointer and therefore the division will not return the number of array elements which may have been the intent.
> 262     				      ARRAY_SIZE(lchan->nr ? h1 : h0));

@Max, has to be
  lchan-nr? ARRAY_SIZE(h1) : ARRAY_SIZE(h0)
so ARRAY_SIZE can be resolved at compile time.

> 263     	}
> 264     	return false;
> 265     }
> 266     
> 267     /* repeat last SID if possible, returns SID length + 1 or 0 */
> 
> 
> ________________________________________________________________________________________________________
> 

-- 
- 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/20161014/772dc55d/attachment.bin>

From holger at freyther.de  Fri Oct 14 04:59:32 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 14 Oct 2016 06:59:32 +0200
Subject: move to gerrit
In-Reply-To: <20161013215814.GA25775@my.box>
References: <20161012144604.GB1481@my.box>
 <20161013160015.mghushf3iery3c2w@nataraja> <20161013215814.GA25775@my.box>
Message-ID: <961878BD-2C04-486B-8751-60C4F9B2BC58@freyther.de>


> On 13 Oct 2016, at 23:58, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> sim/hello-stk
> sim/sim-tools

sysmoUSIM-SJS1 (or other JavaCards).




From laforge at gnumonks.org  Fri Oct 14 07:11:58 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 14 Oct 2016 09:11:58 +0200
Subject: move to gerrit
In-Reply-To: <20161013215814.GA25775@my.box>
References: <20161012144604.GB1481@my.box>
 <20161013160015.mghushf3iery3c2w@nataraja>
 <20161013215814.GA25775@my.box>
Message-ID: <20161014071158.lm46sse6vedjcj5i@nataraja>

Hi Neels,

On Thu, Oct 13, 2016 at 11:58:14PM +0200, Neels Hofmeyr wrote:

> Are these two related to simtrace@ -- because they have 'sim' in the name??
>  sim/hello-stk
>  sim/sim-tools

The answer is only one serach function on osmocom.org away:

https://osmocom.org/projects/sim-card-related/wiki/Shadysimpy

They are tools to work with Java applets on the (not only) sysmocom SIM
cards. They don't have any specific mailing list.  They mgiht benefit
from somebody getting Dieter's patches merged in the upstream shadytel
tools, and not from having more patches merged in our repositories, so I
think gerrit is not a good fit here.

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 axilirator at gmail.com  Fri Oct 14 10:40:44 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 14 Oct 2016 16:40:44 +0600
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAATyM+YjM1EsSY8t9HBbYrzyVRcSjGnZB3GTxwB_bUHxwWFNwQ@mail.gmail.com>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
 <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
 <CAATyM+YjM1EsSY8t9HBbYrzyVRcSjGnZB3GTxwB_bUHxwWFNwQ@mail.gmail.com>
Message-ID: <CAPEnp=bZQFzy-X-BH=moGJVCpxBCa09BS-bZbM7fTppE=-P4zQ@mail.gmail.com>

Hi Tom,

Thank you for explainations!

> Potential Viterbi optimization using SIMD methods is substantial as I
> demonstrated many years ago. The implementation does require
> separation of puncturing and Viterbi. Unfortunately, the has code
> experienced code rot since then. Admittedly, I accept much of that
> blame.

I think it would be really good to have/use your Viterbi implementation
inside the libosmocoding. Regarding to some remarks to your code, I am
ready to fix them (such as malloc -> talloc).

Moreover, recently I had a conversation with Alexander Chemeris. He also
mentioned your implementation, which would be better to use in embedded
platforms (such as UmSITE) due to performance reasons.

> In summary, my concern is about the implementation and not the API.
> Perhaps we could pull the puncturing into the library as Max suggests.
> Then, separately, consider performance changes to the internal
> puncturing and Viterbi implementations.

So, my suggestion is to:

1) Extend your code with encoding capabilities.
2) Merge Viterbi transcoder with the libosmocoding.
3) Merge libosmocoding into libosmocore as a sub-library
   or spawn a separate repository.

Any opinions?


With best regards,
Vadim Yanitskiy.

2016-10-13 1:54 GMT+07:00 Tom Tsou <tom at tsou.cc>:

> On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev at sysmocom.de> wrote:
> > Is there some microbenchmark available? Perhaps we can use it to improve
> > generated code?
>
> Potential Viterbi optimization using SIMD methods is substantial as I
> demonstrated many years ago. The implementation does require
> separation of puncturing and Viterbi. Unfortunately, the has code
> experienced code rot since then. Admittedly, I accept much of that
> blame.
>
> =================================================
> [+] Testing: GSM TCH/AFS 6.7
> [.] Specs: (N=4, K=5, recursive, flushed, punctured)
> [.] Input length  : ret = 140  exp = 140 -> OK
> [.] Output length : ret = 448  exp = 448 -> OK
>
> [.] Performance benchmark:
> [..] Encoding / Decoding 800000 bursts on 8 thread(s):
> [..] Testing base:
> [..] Elapsed time....................... 4.320001 secs
> [..] Rate............................... 25.925920 Mbps
> [..] Testing SIMD:
> [..] Elapsed time....................... 0.458272 secs
> [..] Rate............................... 244.396341 Mbps
> [..] Speedup............................ 9.426718
>
> http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
>
>   -TT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161014/4e71d813/attachment.htm>

From axilirator at gmail.com  Fri Oct 14 10:52:17 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 14 Oct 2016 16:52:17 +0600
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=bZQFzy-X-BH=moGJVCpxBCa09BS-bZbM7fTppE=-P4zQ@mail.gmail.com>
References: <CAPEnp=b7gjh7DRkwRy6b+SzMHSR7Nhnz1MBP6B=GGpkW7X023A@mail.gmail.com>
 <557cba63-267c-0d05-f391-c9150196c944@sysmocom.de>
 <CAATyM+YjM1EsSY8t9HBbYrzyVRcSjGnZB3GTxwB_bUHxwWFNwQ@mail.gmail.com>
 <CAPEnp=bZQFzy-X-BH=moGJVCpxBCa09BS-bZbM7fTppE=-P4zQ@mail.gmail.com>
Message-ID: <CAPEnp=YJc+PhYNc0+ZA1m0CUWDGOWyNaUxQwvii3YVH1YpAUPA@mail.gmail.com>

> 1) Extend your code with encoding capabilities.

Ah, I just found it inside your repository.

With best regards,
Vadim Yanitskiy.

2016-10-14 17:40 GMT+07:00 Vadim Yanitskiy <axilirator at gmail.com>:

> Hi Tom,
>
> Thank you for explainations!
>
> > Potential Viterbi optimization using SIMD methods is substantial as I
> > demonstrated many years ago. The implementation does require
> > separation of puncturing and Viterbi. Unfortunately, the has code
> > experienced code rot since then. Admittedly, I accept much of that
> > blame.
>
> I think it would be really good to have/use your Viterbi implementation
> inside the libosmocoding. Regarding to some remarks to your code, I am
> ready to fix them (such as malloc -> talloc).
>
> Moreover, recently I had a conversation with Alexander Chemeris. He also
> mentioned your implementation, which would be better to use in embedded
> platforms (such as UmSITE) due to performance reasons.
>
> > In summary, my concern is about the implementation and not the API.
> > Perhaps we could pull the puncturing into the library as Max suggests.
> > Then, separately, consider performance changes to the internal
> > puncturing and Viterbi implementations.
>
> So, my suggestion is to:
>
> 1) Extend your code with encoding capabilities.
> 2) Merge Viterbi transcoder with the libosmocoding.
> 3) Merge libosmocoding into libosmocore as a sub-library
>    or spawn a separate repository.
>
> Any opinions?
>
>
> With best regards,
> Vadim Yanitskiy.
>
> 2016-10-13 1:54 GMT+07:00 Tom Tsou <tom at tsou.cc>:
>
>> On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev at sysmocom.de> wrote:
>> > Is there some microbenchmark available? Perhaps we can use it to improve
>> > generated code?
>>
>> Potential Viterbi optimization using SIMD methods is substantial as I
>> demonstrated many years ago. The implementation does require
>> separation of puncturing and Viterbi. Unfortunately, the has code
>> experienced code rot since then. Admittedly, I accept much of that
>> blame.
>>
>> =================================================
>> [+] Testing: GSM TCH/AFS 6.7
>> [.] Specs: (N=4, K=5, recursive, flushed, punctured)
>> [.] Input length  : ret = 140  exp = 140 -> OK
>> [.] Output length : ret = 448  exp = 448 -> OK
>>
>> [.] Performance benchmark:
>> [..] Encoding / Decoding 800000 bursts on 8 thread(s):
>> [..] Testing base:
>> [..] Elapsed time....................... 4.320001 secs
>> [..] Rate............................... 25.925920 Mbps
>> [..] Testing SIMD:
>> [..] Elapsed time....................... 0.458272 secs
>> [..] Rate............................... 244.396341 Mbps
>> [..] Speedup............................ 9.426718
>>
>> http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
>>
>>   -TT
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161014/50c80092/attachment.htm>

From nhofmeyr at sysmocom.de  Fri Oct 14 13:04:05 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 14 Oct 2016 15:04:05 +0200
Subject: moved to gerrit patch submission
Message-ID: <20161014130405.GB25300@ass40.sysmocom.de>

The following git repositories have now moved to gerrit, please submit
future patches for these at gerrit.osmocom.org, no longer via mailing
lists:

osmo-gsm-manuals
asn1c
libasn1c
osmo-trx
openpcd
osmo-sim-auth
libtelnet
mncc-python
osmocom-lcs

Thanks,

~Neels

-- 
- 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/20161014/58d5b2f9/attachment.bin>

From laforge at gnumonks.org  Fri Oct 14 14:41:01 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 14 Oct 2016 16:41:01 +0200
Subject: bind & connect
In-Reply-To: <20161013213917.GA19440@my.box>
References: <20161013213917.GA19440@my.box>
Message-ID: <20161014144101.mfgepcgug36dsnp7@nataraja>

On Thu, Oct 13, 2016 at 11:39:17PM +0200, Neels Hofmeyr wrote:
> But how would I tell the IuPS to use a given local interface 1.2.3.5 to contact
> the SGSN's address? 

Please note that on Linux, addresses are always addresses of the overall
host / IP stack and not of a specific interface.  The routing table
is used to determine the local address that should be used for a given
destination.

So for (almost?) all reasonably configured systems, it should simply
work based on what the system administrator has set.

> Would I bind() to a given local IP address and connect() to the remote
> one?

yes.

> AFAIK it can be important to set a local IP address and port to send
> from. 

I think in general this would mostly be a work-around for broken setups.

At least, when talking about TCP clients here.  Binding UDP or TCP
server sockets is of course a different story

> Anyway, in osmo_sock_init, I see:
> 
>         if ((flags & (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) ==
>                      (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) {
>                 fprintf(stderr, "invalid: both bind and connect flags set:"
>                         " %s:%u\n", host, port);
>                 return -EINVAL;
>         }

well, because we only pass one pair of host+port parameters into
osmo_sock_init(), you cannot bind and connect to that same host:port,
unless you insist to only talk to yourself.



> Should we have another osmo_sock_init that can set up a socket like this code I
> found somewhere at sysmocom to define both ends of a connection?

I'm not sure if it should be a new function for both connect + bind at
the same time, or we simply bind using osmo_sock_init() and then have
another call for the connect?

In any case, this is one of the things I wouldn't bother unless
somebody really indicates he needs 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 nhofmeyr at sysmocom.de  Sun Oct 16 21:55:33 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 16 Oct 2016 23:55:33 +0200
Subject: bind & connect
In-Reply-To: <20161014144101.mfgepcgug36dsnp7@nataraja>
References: <20161013213917.GA19440@my.box>
 <20161014144101.mfgepcgug36dsnp7@nataraja>
Message-ID: <20161016215533.GA3138@my.box>

On Fri, Oct 14, 2016 at 04:41:01PM +0200, Harald Welte wrote:
> > Would I bind() to a given local IP address and connect() to the remote
> > one?
> 
> yes.

> In any case, this is one of the things I wouldn't bother unless
> somebody really indicates he needs it.

Ok, will not bother then.

Out of curiosity...

So normally when I send something, the routing table (ip r show) determines
which local interface the remote side sees as sender.

If I connect() and bind() at the same time, would that bypass the routing table
and the bind() address would be the sender?

And that's why we don't really need it, because it doesn't make sense to send
from a different interface than indicated by the routing table?


-- 
- 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/20161016/2377b6f6/attachment.bin>

From laforge at gnumonks.org  Sun Oct 16 22:13:19 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 17 Oct 2016 00:13:19 +0200
Subject: bind & connect
In-Reply-To: <20161016215533.GA3138@my.box>
References: <20161013213917.GA19440@my.box>
 <20161014144101.mfgepcgug36dsnp7@nataraja>
 <20161016215533.GA3138@my.box>
Message-ID: <20161016221319.jxhtpohnedp4y2wb@nataraja>

On Sun, Oct 16, 2016 at 11:55:33PM +0200, Neels Hofmeyr wrote:

> So normally when I send something, the routing table (ip r show) determines
> which local interface the remote side sees as sender.

Yes.  Please note 'ip r show' will only show you 'table main'.  Since
Linux 2.2.x (yes, ages ago) Linux supports and uses multiple routin
tables.  See 'ip route show table all' to see all routes that exist in
the stack.

If you didn't bind a socket and send a packet, it works more or less
like this:

* The kernel performs a route lookup and finds an outbound route for the
  destination. If the route contains the src parameter, the kernel
  selects this IP address for the outbound packet.

* If no 'src' parameter is in the route, the kernel will choose the
  first address configured on the interface which falls in the same
  network as the destination address or the nexthop router.

See http://linux-ip.net/html/routing-saddr-selection.html

> If I connect() and bind() at the same time, would that bypass the routing table
> and the bind() address would be the sender?

yes, if you explicitly bind before using the socket, you will bypass the
regular automatic source address selection of the kernel.

> And that's why we don't really need it, because it doesn't make sense to send
> from a different interface than indicated by the routing table?

well, it sometimes makes sense in more complex scenarios with
multi-homed machines, but I think we can ignore that until somebody
requests it.

Also, in a lot of cases it makes sense to store such configuration in
the routing table itself, rather than inside the applicatin config.
Chances are that other applications/services wanting to reach the same
destination address/network will have to choose the same source address.

So something like 'ip route add 8.8.8.8/32 via 192.168.100.1 src 1.2.3.4'
will teach the routing table to choose the local source address 1.2.3.4
whenever sending packets to 8.8.8.8 and route them via the gateway
192.168.100.1.  This configuration is valid system-wide, for all
applications/sockets.  Please note that 1.2.3.4 must be a valid local
address (i.e. one that has been added using 'ip addr add 1.2.3.4 ...'
before.

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  Sun Oct 16 22:57:35 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 17 Oct 2016 00:57:35 +0200
Subject: bind & connect
In-Reply-To: <20161016221319.jxhtpohnedp4y2wb@nataraja>
References: <20161013213917.GA19440@my.box>
 <20161014144101.mfgepcgug36dsnp7@nataraja>
 <20161016215533.GA3138@my.box>
 <20161016221319.jxhtpohnedp4y2wb@nataraja>
Message-ID: <20161016225735.GA7663@my.box>

On Mon, Oct 17, 2016 at 12:13:19AM +0200, Harald Welte wrote:
> On Sun, Oct 16, 2016 at 11:55:33PM +0200, Neels Hofmeyr wrote:
> 
> > So normally when I send something, the routing table (ip r show) determines
> > which local interface the remote side sees as sender.
> 
> Yes.  Please note 'ip r show' will only show you 'table main'.  Since
> Linux 2.2.x (yes, ages ago) Linux supports and uses multiple routin
> tables.  See 'ip route show table all' to see all routes that exist in
> the stack.

yep, that was a gotcha when I started to get used to Freifunk -- scratching my
head at the main table until I saw a hundred more routes in tables 'olsr' and
'olsr-default' (and having to fix the table priorities...)

[...]
> See http://linux-ip.net/html/routing-saddr-selection.html
[...]
> So something like 'ip route add 8.8.8.8/32 via 192.168.100.1 src 1.2.3.4'
> will teach the routing table to choose the local source address 1.2.3.4
> whenever sending packets to 8.8.8.8 and route them via the gateway
> 192.168.100.1.  This configuration is valid system-wide, for all
> applications/sockets.  Please note that 1.2.3.4 must be a valid local
> address (i.e. one that has been added using 'ip addr add 1.2.3.4 ...'
> before.

Thanks for the excellent explanation and link!
It's very clear to me now.

-- 
- 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/20161017/af179c66/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 17 14:51:52 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 17 Oct 2016 16:51:52 +0200
Subject: creepy dirs in osmo-bts/tests
Message-ID: <80815380-7495-89d6-1c35-b32de058c9d6@sysmocom.de>

Hi.

I've ran "make check" in osmo-bts recently ang got weird dir names in
tests/*/ like '$srcdir' - it seems like those should be evaluated
variable but it's written literally to FS. Do you guys see it as well or
it's some glitch local to my shell?

-- 
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  Mon Oct 17 15:06:22 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 17 Oct 2016 17:06:22 +0200
Subject: osmo-bts-trx channel activation
Message-ID: <e66b39b3-b65f-9fc5-6c9e-2f2b48ffdaa5@sysmocom.de>

Hi.

In sysmobts we use ugly hack to auto-activate BCCH/CCCH on TS0 via
opstart_compl(). How does channel activation looks like for osmo-bts-trx?

On a related note: how do we decide on number of AGCH? In case of
sysmobts it's communicated to L1 in agch.u8NbrOfAgch via lch_par.  What
would be equivalent for osmo-bts-trx?

-- 
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  Mon Oct 17 15:44:31 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 17 Oct 2016 17:44:31 +0200
Subject: creepy dirs in osmo-bts/tests
In-Reply-To: <80815380-7495-89d6-1c35-b32de058c9d6@sysmocom.de>
References: <80815380-7495-89d6-1c35-b32de058c9d6@sysmocom.de>
Message-ID: <20161017154431.GA2490@my.box>

I would have said that's the 'subdir-objects' bug of autoconf, but osmo-bts
doesn't have it enabled...

so I ran 'make test' in my osmo-bts and got no weird dirs.



## ----------------------------------- ##
## osmo-bts 0.4.0.301-2114 test suite. ##
## ----------------------------------- ##

Regression tests.

  1: paging                                          ok
  2: agch                                            ok
  3: cipher                                          ok
  4: misc                                            ok
  5: bursts                                          ok
  6: handover                                        ok

## ------------- ##
## Test results. ##
## ------------- ##

All 6 tests were successful.
make[3]: Leaving directory '/n/s/osmo/git/osmo-bts/tests'
make[2]: Leaving directory '/n/s/osmo/git/osmo-bts/tests'
make[1]: Leaving directory '/n/s/osmo/git/osmo-bts/tests'
make[1]: Entering directory '/n/s/osmo/git/osmo-bts'
make[1]: Leaving directory '/n/s/osmo/git/osmo-bts'

??????????????????????????????????????????????????????????????????????????????? 
? ls tests/*
tests/atconfig  tests/Makefile.am  tests/package.m4  tests/testsuite*    tests/testsuite.log
tests/Makefile  tests/Makefile.in  tests/stubs.c     tests/testsuite.at

tests/agch:
agch_test*  agch_test.c  agch_test.o  agch_test.ok  Makefile  Makefile.am  Makefile.in  stubs.o

tests/bursts:
bursts_test*   bursts_test.ok    gsm0503_interleaving.o  gsm0503_tables.o  Makefile.in
bursts_test.c  gsm0503_coding.o  gsm0503_mapping.o       Makefile
bursts_test.o  gsm0503_conv.o    gsm0503_parity.o        Makefile.am

tests/cipher:
cipher_test*  cipher_test.c  cipher_test.o  cipher_test.ok  Makefile  Makefile.am  Makefile.in  stubs.o

tests/handover:
handover_test*  handover_test.c  handover_test.o  handover_test.ok  Makefile  Makefile.am  Makefile.in

tests/misc:
Makefile  Makefile.am  Makefile.in  misc_test*  misc_test.c  misc_test.o  misc_test.ok  stubs.o

tests/paging:
Makefile  Makefile.am  Makefile.in  paging_test*  paging_test.c  paging_test.o  paging_test.ok  stubs.o

tests/sysmobts:
Makefile  Makefile.am  Makefile.in  sysmobts_test.c  sysmobts_test.ok

tests/testsuite.dir:




On Mon, Oct 17, 2016 at 04:51:52PM +0200, Max wrote:
> Hi.
> 
> I've ran "make check" in osmo-bts recently ang got weird dir names in
> tests/*/ like '$srcdir' - it seems like those should be evaluated
> variable but it's written literally to FS. Do you guys see it as well or
> it's some glitch local to my shell?
> 
> -- 
> 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 
> 

-- 
- 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/20161017/85a043ca/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 17 15:57:05 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 17 Oct 2016 17:57:05 +0200
Subject: osmo-trx gerrit
Message-ID: <20161017155705.GB2490@my.box>

<bump> https://gerrit.osmocom.org/1067

Would be nice to have the build script in master, and at the same time verify
that you have +2 voting powers on osmo-trx -- you're currently the only one
there. Feel free to appoint other reviewers at your discretion (tell me).

Thanks!

~Neels

-- 
- 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/20161017/9404bce3/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 17 16:13:14 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 17 Oct 2016 18:13:14 +0200
Subject: osmo-trx and gpsdo
In-Reply-To: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
References: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
Message-ID: <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>

Here are some more details:

./Transceiver52M/osmo-trx -c 2 -l INFO -g

INFO 3041433344 18:06:51.9 UHDDevice.cpp:743:parse_dev_type: Using USRP1
type transmit window for B-Series Device B210
terminate called after throwing an instance of 'uhd::key_error'
  what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo

Program received signal SIGABRT, Aborted.

#0  0xb7fdd428 in __kernel_vsyscall ()
#1  0xb7108687 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb710bab3 in __GI_abort () at abort.c:89
#3  0xb7339405 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/i386-linux-gnu/libstdc++.so.6
#4  0xb7337063 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5  0xb733709f in std::terminate() () from
/usr/lib/i386-linux-gnu/libstdc++.so.6
#6  0xb7337306 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#7  0xb7b3cdaf in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#8  0xb7b5fb29 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#9  0xb76edaa5 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#10 0xb76eddb7 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#11 0xb77d138a in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#12 0xb77d1406 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
#13 0x0807f912 in uhd_device::open (this=0x81720e8, args="", ref=2,
swap_channels=false) at UHDDevice.cpp:848
#14 0x08052f8f in main (argc=6, argv=0xbffffc34) at osmo-trx.cpp:528

or full trace:

#0  0xb7fdd428 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7108687 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = <optimized out>
        resultvar = <optimized out>
        pid = -1222094848
        selftid = 7509
#2  0xb710bab3 in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x819e604,
sa_sigaction = 0x819e604}, sa_mask = {__val = {65, 3071582317,
              3072874848, 3087003648, 3086538904, 5, 3221221200,
3086926177, 3086539344, 3041440256, 1, 5, 0, 3072872448, 3072874848,
              3072878732, 3221221172, 3074215964, 3073382156,
3073321628, 135792864, 3072872448, 3072874848, 3071148324, 3072874848,
              3071545388, 3074215936, 3074215936, 135521124, 135915012,
135793824, 3086951616}}, sa_flags = 135792816,
          sa_restorer = 0xb710b970 <__GI_abort>}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#3  0xb7339405 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#4  0xb7337063 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#5  0xb733709f in std::terminate() () from
/usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#6  0xb7337306 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#7  0xb7b3cdaf in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#8  0xb7b5fb29 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#9  0xb76edaa5 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#10 0xb76eddb7 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#11 0xb77d138a in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#12 0xb77d1406 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
No symbol table info available.
#13 0x0807f912 in uhd_device::open (this=0x81720e8, args="", ref=2,
swap_channels=false) at UHDDevice.cpp:848
        refstr = <optimized out>
        __FUNCTION__ = "open"
        _rx_rate = <optimized out>
        _tx_rate = <optimized out>
        addr = {<uhd::dict<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >> = {_map = empty
std::list}, <No data fields>}
        dev_addrs = std::vector of length 1, capacity 1 = {
          {<uhd::dict<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >> = {_map = std::list = {[0] = {first = "type",
second = "b200"}, [1] = {first = "name",
                  second = "MyB210"}, [2] = {first = "serial", second =
"30AC26A"}, [3] = {first = "product",
                  second = "B210"}}}, <No data fields>}}
        stream_args = {cpu_format = "", otw_format = "",
          args = {<uhd::dict<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >> = {_map = std::list =
{[0] = {
                  first = <error reading variable: Cannot access memory
at address 0xfffffff4>,
                  second = <error reading variable: Cannot access memory
at address 0xfffffff4>}, [1] = {
                  first = <error reading variable: Cannot access memory
at address 0xfffffff5>,
                  second =
"H{\367\267\020\a\030\b\330C\030\bXG\027\b\030\002\030\b\000ice", '\000'
<repeats 12 times>,
"\061\000\000\000/lib/i386-linux-gnu/libnss_files.so.2\000_minim\231",
'\000' <repeats 35 times>,
"\202\364\374\267\205\317c\t\000\000\000\000\000\000\000\000\272\364\374\267\020ii\r\000\000\000\000f\364\374\267\260\364\374\267\022ii\r\000\000\000\000f\364\374\267\202\364\374\267\205\317c\t\000\000\000\000f\364\374\267\246\364\374\267\021ii\r\000\000\000\000f\364",
<incomplete sequence \374\267>...}, [2] = {
                  first = "", second = ""}, [3] = {first = <error
reading variable: Cannot access memory at address 0x8b007bc4>,
                  second = <error reading variable: Cannot access memory
at address 0x8d042438>}<error reading variable: Cannot access memory at
address 0xec2ea7e8>...}}, <No data fields>}, channels = std::vector of
length 149430, capacity -33734559 = {3515007873,
            4135911432, 2206953844, 1216, 1853145221, 1352696715,
76087296, 2526079012, 881459199, 3902013220, 2332033028, 5300371,
            1002580224, 5310611, 3767765248, 2113929296, 143886598,
2332033105, 5309571, 32015104, 1361871675, 2206793728, 20740,
            2206795390, 20780, 4280562825, 319635, 2692975360,
2298478672, 2548573188, 2214592406, 1583027396, 881430723, 3767795492,
            2197815300, 1583027396, 827822275, 3330889471, 283935571,
535298187, 2181036619, 147906499, 1958774016, 607422734,
            3338948863, 6, 2311555328, 803742772, 2214592511,
4169732292, 3277807195, 46733, 2304049152, 2304137173, 3968029638,
            1256253484, 3280076794, 577696, 2215624837, 338, 2383401605,
394, 4202807345, 2147483391, 16682767, 881393664,
            3902013220, 2298478596, 1149838380, 2482964516, 1260,
4035561353, 136608827, 14320655, 2475360256, 1216, 2215629445, 218,
            1352696715, 76087296, 2506942500, 2872836095, 20764,
1358211977, 108920832, 1360833417, 4169728000, 136594475, 203703433,
            1356891019, 1418395648, 3246984228, 2300574145, 2299798604,
536461777, 405034121, 1352962955, 1284046848, 2341149732,
            20648, 405034027, 472140827, 337923129, 270812297, 8686863,
2089353216, 881394724, 3834904356, 2231369732, 264407488,
            38276, 605325568, 203707529, 82351103, 1418395648,
1143671844, 2198013988, 20704, 1359512379, 2206793728, 20704,
            2206795390, 20744, 1352696715, 1418264576, 76089380,
2501175332, 1418461183, 3498641444, 1529660547, 3277676382, 46733,
            2089353216, 881394724, 3834904356, 2197815300, 1583033540,
2378390879, 142540918, 2182074425, 4294967154, 203703435,
            4288071144, 4284803583, 3296985087, 1540393260, 3915210590,
4294964050, 2206961766, 20652, 2423570565, 2682841225,
            2315255702, 2298750076, 2482971700, 1252, 3263807621,
4285694991, 1055522815, 2382364671, 76087414, 4251510820,
            3224502271, 4294931433, 1465225471, 1405520214, 2334977155,
535322744, 2181036617, 147775427, 609519872, 2111256860,
            108560390, 822834432, 751076288, 1566531163, 1416335555,
2334923812, 65559616, 2315255806, 506053, 3984916480,
            1150017396, 3614120996, 608487212, 4, 33040640, 750808042,
2300843145, 2300060756, 3892847684, 4294562882, 405034123,
            3948703369, 2383384683, 178, 1116285577, 877038340,
405034121, 3088597641...}}
#14 0x08052f8f in main (argc=6, argv=0xbffffc34) at osmo-trx.cpp:528
        type = <optimized out>
        chans = <optimized out>
        ref = 2
        usrp = 0x81720e8
        radio = 0x0
        config = {log_level = "INFO", addr = "127.0.0.1", dev_args = "",
port = 5700, tx_sps = 4, rx_sps = 1, chans = 2, rtsc = 0,
          rach_delay = 0, extref = false, gpsref = true, filler =
Transceiver::FILLER_ZERO, diversity = false, mcbts = false,
          offset = 0, rssi_offset = 0, swap_channels = false, edge = false}
        __FUNCTION__ = "main"
        trx = 0x0
        iface = <optimized out>

Could this have something to do with uhd version
(UHD_003.010.000.000-release) I'm using? It seems like SIGABRT happens
somewhere deep in uhd intestines.

Or maybe it's some obvious misconfiguration which I've failed to notice
so far?


On 10/13/2016 01:43 PM, Max wrote:
> Hi.
>
> While trying to make osmo-trx work in multichannel configuration I've
> found following:
> - running "./Transceiver52M/osmo-trx -m -c 2 -l INFO" works but
> - running "./Transceiver52M/osmo-trx -m -c 2 -l INFO -g" gives following:
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.000.000-release
>                                   
> opening configuration table from path :memory:
> Config Settings                   
>    Log Level............... INFO  
>    Device args.............       
>    TRX Base Port........... 5700  
>    TRX Address............. 127.0.0.1
>    Channels................ 2     
>    Tx Samples-per-Symbol... 4     
>    Rx Samples-per-Symbol... 4     
>    EDGE support............ Disabled
>    Reference............... GPS   
>    C0 Filler Table......... Disabled
>    Multi-Carrier........... Enabled
>    Diversity............... Disabled
>    Tuning offset........... 0     
>    RSSI to dBm offset...... 0     
>    Swap channels........... 0     
>                                   
> INFO 3032180480 13:36:38.4 UHDDevice.cpp:786:open: Using discovered UHD
> device type=b200,name=MyB210,serial=30AC26A,product=B210
> -- Detected Device: B210          
> -- Operating over USB 2.          
> -- Initialize CODEC control...    
> -- Initialize Radio control...    
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> -- Asking for clock rate 16.000000 MHz...
> -- Actually got clock rate 16.000000 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> INFO 3032180480 13:36:41.6 UHDDevice.cpp:743:parse_dev_type: Using USRP1
> type transmit window for B-Series Device B210
> terminate called after throwing an instance of 'uhd::key_error'
>   what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo
> Aborted (core dumped)             
>
> The tests were performed with usrp B210 and rather recent uhd (see
> above). Is this some know error/hw incompatibility?
>

-- 
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 ikostov at sysmocom.de  Mon Oct 17 17:27:02 2016
From: ikostov at sysmocom.de (Ivaylo Kostov)
Date: Mon, 17 Oct 2016 19:27:02 +0200
Subject: Probleme mit pySim
Message-ID: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>

Hallo zusammen,

wegen meines Versuch die pySim zu verwenden habe ich folgendes bekommen:

> ./pySim-read.py -p 0
> Reading ...
> Traceback (most recent call last):
>   File "./pySim-read.py", line 90, in <module>
>     (res, sw) = scc.read_binary(['3f00', '2fe2'])
>   File "/home/wirelesss/net/pysim/pySim/commands.py", line 51, in 
> read_binary
>     r = self.select_file(ef)
>   File "/home/wirelesss/net/pysim/pySim/commands.py", line 44, in 
> select_file
>     data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
>   File "/home/wirelesss/net/pysim/pySim/transport/__init__.py", line 
> 87, in send_apdu_checksw
>     raise RuntimeError("SW match failed ! Expected %s and got %s." % 
> (sw.lower(), rv[1]))
> RuntimeError: SW match failed ! Expected 9000 and got 6b00.
> $ ./pySim-read.py -p 1
> Traceback (most recent call last):
>   File "./pySim-read.py", line 78, in <module>
>     sl = PcscSimLink(opts.pcsc_dev)
>   File "/home/wirelesss/net/pysim/pySim/transport/pcsc.py", line 38, 
> in __init__
>     self._reader = r[reader_number]
> IndexError: list index out of range
> Exception AttributeError: "'PcscSimLink' object has no attribute 
> '_con'" in <bound method PcscSimLink.__del__ of 
> <pySim.transport.pcsc.PcscSimLink object at 0x7f3dca255750>> ignored

wenn man ./pySim-prog.py gebe, dann das Ergebnis auch nicht so richtig ist.


> ./pySim-prog.py -p 0 -t sysmosim-gr1 -i 001640000000072 -c 001 -x 001 
> -y 64 -s 1791198229180000071
> Insert card now (or CTRL-C to cancel)
> Generated card parameters :
>  > Name    : Magic
>  > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
>  > ICCID   : 1791198229180000071
>  > MCC/MNC : 1/64
>  > IMSI    : 001640000000072
>  > Ki      : 895c5a0e9e5f635111d6c366ae8c957f
>  > OPC     : a230dcc3c71c17019189a8be734f9c74
>  > ACC     : None
>
> Programming ...
> Traceback (most recent call last):
>   File "./pySim-prog.py", line 626, in <module>
>     card.program(cp)
>   File "/home/wirelesss/net/pysim/pySim/cards.py", line 274, in program
>     r = self._scc.select_file(['3f00', '2fe2'])
>   File "/home/wirelesss/net/pysim/pySim/commands.py", line 44, in 
> select_file
>     data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
>   File "/home/wirelesss/net/pysim/pySim/transport/__init__.py", line 
> 87, in send_apdu_checksw
>     raise RuntimeError("SW match failed ! Expected %s and got %s." % 
> (sw.lower(), rv[1]))
> RuntimeError: SW match failed ! Expected 9000 and got 6b00.

Kommando: pcsc_scan funktioniert reibungslos.

Gr??e,
            Ivaylo

-- 
- Ivaylo Kostov  <ikostov 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



From tom.tsou at ettus.com  Mon Oct 17 19:01:20 2016
From: tom.tsou at ettus.com (Tom Tsou)
Date: Mon, 17 Oct 2016 12:01:20 -0700
Subject: osmo-trx gerrit
In-Reply-To: <20161017155705.GB2490@my.box>
References: <20161017155705.GB2490@my.box>
Message-ID: <CAGNiu+epGxBQwjVCVf+BNi9cWs9PM0nwQSokuj+AEP2QyRRGmw@mail.gmail.com>

Submitted.

  -TT

On Mon, Oct 17, 2016 at 8:57 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> <bump> https://gerrit.osmocom.org/1067
>
> Would be nice to have the build script in master, and at the same time
> verify
> that you have +2 voting powers on osmo-trx -- you're currently the only one
> there. Feel free to appoint other reviewers at your discretion (tell me).
>
> Thanks!
>
> ~Neels
>
> --
> - 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/20161017/3eb7a03c/attachment.htm>

From tom at tsou.cc  Mon Oct 17 23:08:41 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 17 Oct 2016 16:08:41 -0700
Subject: osmo-trx and gpsdo
In-Reply-To: <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>
References: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
 <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>
Message-ID: <CAATyM+Yx=qqLCJdSXy64WB_9AKO3cXBo=Dnrn04WO1EGtaBiBQ@mail.gmail.com>

Thanks Max,

On Mon, Oct 17, 2016 at 9:13 AM, Max <msuraev at sysmocom.de> wrote:
> ./Transceiver52M/osmo-trx -c 2 -l INFO -g
>
> INFO 3041433344 18:06:51.9 UHDDevice.cpp:743:parse_dev_type: Using USRP1
> type transmit window for B-Series Device B210
> terminate called after throwing an instance of 'uhd::key_error'
>   what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo

I reproduced the gpsdo issue on my machine. This looks like something
UHD version related. I'm looking into it.

  -TT


From nhofmeyr at sysmocom.de  Mon Oct 17 23:10:04 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 18 Oct 2016 01:10:04 +0200
Subject: Probleme mit pySim
In-Reply-To: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
References: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
Message-ID: <20161017231004.GB17532@my.box>

Dear Ivo,

openbsc@ is an English language mailing list. If you'd like to write in German,
you can always send to sysmocom internally.

(I have answered this mail privately, offering another SIM card to test with.)

-- 
- 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/20161018/8e3a1e06/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Oct 17 23:33:57 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 18 Oct 2016 01:33:57 +0200
Subject: osmo-trx gerrit
In-Reply-To: <CAGNiu+epGxBQwjVCVf+BNi9cWs9PM0nwQSokuj+AEP2QyRRGmw@mail.gmail.com>
References: <20161017155705.GB2490@my.box>
 <CAGNiu+epGxBQwjVCVf+BNi9cWs9PM0nwQSokuj+AEP2QyRRGmw@mail.gmail.com>
Message-ID: <20161017233357.GC17532@my.box>

On Mon, Oct 17, 2016 at 12:01:20PM -0700, Tom Tsou wrote:
> Submitted.

Saw it, excellent and thanks :)

-- 
- 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/20161018/dcf34981/attachment.bin>

From tom at tsou.cc  Tue Oct 18 00:06:42 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 17 Oct 2016 17:06:42 -0700
Subject: osmo-trx and gpsdo
In-Reply-To: <CAATyM+Yx=qqLCJdSXy64WB_9AKO3cXBo=Dnrn04WO1EGtaBiBQ@mail.gmail.com>
References: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
 <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>
 <CAATyM+Yx=qqLCJdSXy64WB_9AKO3cXBo=Dnrn04WO1EGtaBiBQ@mail.gmail.com>
Message-ID: <CAATyM+aERRKmcUHOgYqsx9jPPcKiXBTvkkRo4e4vXXFfa-gezA@mail.gmail.com>

On Mon, Oct 17, 2016 at 4:08 PM, Tom Tsou <tom at tsou.cc> wrote:
> On Mon, Oct 17, 2016 at 9:13 AM, Max <msuraev at sysmocom.de> wrote:
>> ./Transceiver52M/osmo-trx -c 2 -l INFO -g
>>
>> INFO 3041433344 18:06:51.9 UHDDevice.cpp:743:parse_dev_type: Using USRP1
>> type transmit window for B-Series Device B210
>> terminate called after throwing an instance of 'uhd::key_error'
>>   what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo
>
> I reproduced the gpsdo issue on my machine. This looks like something
> UHD version related. I'm looking into it.

Do you have a GPSDO installed in the B210?

In either case this is a bug in UHD. I want to check that all
configurations are covered.

  -TT


From nhofmeyr at sysmocom.de  Tue Oct 18 00:15:39 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 18 Oct 2016 02:15:39 +0200
Subject: new warnings because of ctrl constify
Message-ID: <20161018001539.GA10319@my.box>

Presumably after this libosmocore commit, I get scores of new warnings (see
below) when compiling openbsc:

commit ed9d6da5df98538adc70aa03cb569eb9505d04b6
Author:     Max <msuraev at sysmocom.de>
AuthorDate: Tue Oct 11 15:20:28 2016 +0200

    Constify ctrl_cmd struct fields where appropriate



Some of these can be fixed by constifying the functions as well, but
talloc_free() of a const char * looks really wrong?

Please follow up on this or revert the commit... constifying is good, but
having twice the amount of warnings means twice the reading effort during
development cycles.

I would most prefer a revert now and come back as soon as no new warnings are
introduced; ymmv...


In file included from /usr/local/include/osmocom/core/talloc.h:4:0,
                 from ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:22:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?bsc_nat_handle_ctrlif_msg?:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:131:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
    talloc_free(cmd->variable);
                ^
/usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
 int _talloc_free(void *ptr, const char *location);
     ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:143:34: warning: passing argument 2 of ?bsc_get_pending? discards ?const? qualifier from pointer target type
   pending = bsc_get_pending(bsc, cmd->id);
                                  ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:86:29: note: expected ?char *? but argument is of type ?const char *?
 static struct bsc_cmd_list *bsc_get_pending(struct bsc_connection *bsc, char *id_str)
                             ^
../../../src/osmo-bsc_nat/bsc_ussd.c: In function ?bsc_ussd_check?:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?forward_to_bsc?:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:228:31: warning: passing argument 1 of ?extract_bsc_nr_variable? discards ?const? qualifier from pointer target type
  if (!extract_bsc_nr_variable(cmd->variable, &nr, &bsc_variable)) {
                               ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:198:12: note: expected ?char *? but argument is of type ?const char *?
 static int extract_bsc_nr_variable(char *variable, unsigned int *nr, char **bsc_variable)
            ^
In file included from /usr/local/include/osmocom/core/talloc.h:4:0,
                 from ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:22:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:259:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
    talloc_free(bsc_cmd->id);
                ^
/usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
 int _talloc_free(void *ptr, const char *location);
     ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:266:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
    talloc_free(bsc_cmd->variable);
                ^
/usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
 int _talloc_free(void *ptr, const char *location);
     ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?extract_bsc_cfg_variable?:
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:323:31: warning: passing argument 1 of ?extract_bsc_nr_variable? discards ?const? qualifier from pointer target type
  if (!extract_bsc_nr_variable(cmd->variable, &nr, bsc_variable)) {
                               ^
../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:198:12: note: expected ?char *? but argument is of type ?const char *?
 static int extract_bsc_nr_variable(char *variable, unsigned int *nr, char **bsc_variable)
            ^




-- 
- 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/20161018/f99b4201/attachment.bin>

From msuraev at sysmocom.de  Tue Oct 18 08:06:51 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 18 Oct 2016 10:06:51 +0200
Subject: osmo-trx and gpsdo
In-Reply-To: <CAATyM+aERRKmcUHOgYqsx9jPPcKiXBTvkkRo4e4vXXFfa-gezA@mail.gmail.com>
References: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
 <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>
 <CAATyM+Yx=qqLCJdSXy64WB_9AKO3cXBo=Dnrn04WO1EGtaBiBQ@mail.gmail.com>
 <CAATyM+aERRKmcUHOgYqsx9jPPcKiXBTvkkRo4e4vXXFfa-gezA@mail.gmail.com>
Message-ID: <e07e2147-e0f7-c81e-1819-4baeab1d1522@sysmocom.de>

How do I check that? Also, should adding/removing GPS antennae make any
difference?


On 10/18/2016 02:06 AM, Tom Tsou wrote:
> On Mon, Oct 17, 2016 at 4:08 PM, Tom Tsou <tom at tsou.cc> wrote:
>> On Mon, Oct 17, 2016 at 9:13 AM, Max <msuraev at sysmocom.de> wrote:
>>> ./Transceiver52M/osmo-trx -c 2 -l INFO -g
>>>
>>> INFO 3041433344 18:06:51.9 UHDDevice.cpp:743:parse_dev_type: Using USRP1
>>> type transmit window for B-Series Device B210
>>> terminate called after throwing an instance of 'uhd::key_error'
>>>   what():  LookupError: KeyError: update_clock_source: unknown source: gpsdo
>> I reproduced the gpsdo issue on my machine. This looks like something
>> UHD version related. I'm looking into it.
> Do you have a GPSDO installed in the B210?
>
> In either case this is a bug in UHD. I want to check that all
> configurations are covered.
>
>   -TT

-- 
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 holger at freyther.de  Tue Oct 18 09:23:42 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 18 Oct 2016 11:23:42 +0200
Subject: Probleme mit pySim
In-Reply-To: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
References: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
Message-ID: <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>


> On 17 Oct 2016, at 19:27, Ivaylo Kostov <ikostov at sysmocom.de> wrote:
> 
>> ./pySim-read.py -p 0
>> Reading ...
>> Traceback (most recent call last):
>>  File "./pySim-read.py", line 90, in <module>
>>    (res, sw) = scc.read_binary(['3f00', '2fe2'])
>>  File "/home/wirelesss/net/pysim/pySim/commands.py", line 51, in read_binary
>>    r = self.select_file(ef)
>>  File "/home/wirelesss/net/pysim/pySim/commands.py", line 44, in select_file
>>    data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
>>  File "/home/wirelesss/net/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
>>    raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
>> RuntimeError: SW match failed ! Expected 9000 and got 6b00.

I think master has issues with the GR1 card, e.g. try e9e5ecbe3068dae7e6e0959f22ed1855911dc892

holger

From ikostov at sysmocom.de  Tue Oct 18 09:52:41 2016
From: ikostov at sysmocom.de (Ivaylo Kostov)
Date: Tue, 18 Oct 2016 11:52:41 +0200
Subject: Probleme mit pySim
In-Reply-To: <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>
References: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
 <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>
Message-ID: <adab149a-116a-01d8-fb0f-294415f5a67b@sysmocom.de>

Hi Holger,

Thank you!

Ivaylo

On 10/18/2016 11:23 AM, Holger Freyther wrote:
>> On 17 Oct 2016, at 19:27, Ivaylo Kostov <ikostov at sysmocom.de> wrote:
>>
>>> ./pySim-read.py -p 0
>>> Reading ...
>>> Traceback (most recent call last):
>>>   File "./pySim-read.py", line 90, in <module>
>>>     (res, sw) = scc.read_binary(['3f00', '2fe2'])
>>>   File "/home/wirelesss/net/pysim/pySim/commands.py", line 51, in read_binary
>>>     r = self.select_file(ef)
>>>   File "/home/wirelesss/net/pysim/pySim/commands.py", line 44, in select_file
>>>     data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
>>>   File "/home/wirelesss/net/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
>>>     raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
>>> RuntimeError: SW match failed ! Expected 9000 and got 6b00.
> I think master has issues with the GR1 card, e.g. try e9e5ecbe3068dae7e6e0959f22ed1855911dc892
>
> holger

-- 
- Ivaylo Kostov  <ikostov 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/20161018/ed4bc86d/attachment.htm>

From nhofmeyr at sysmocom.de  Tue Oct 18 09:57:34 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 18 Oct 2016 11:57:34 +0200
Subject: pySim current master fails for sysmosim-gr1
In-Reply-To: <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>
References: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
 <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>
Message-ID: <20161018095734.GA1521@ass40.sysmocom.de>

On Tue, Oct 18, 2016 at 11:23:42AM +0200, Holger Freyther wrote:
> 
> > On 17 Oct 2016, at 19:27, Ivaylo Kostov <ikostov at sysmocom.de> wrote:
> > 
> >> ./pySim-read.py -p 0
> >> Reading ...
> >> Traceback (most recent call last):
> >>  File "./pySim-read.py", line 90, in <module>
> >>    (res, sw) = scc.read_binary(['3f00', '2fe2'])
> >>  File "/home/wirelesss/net/pysim/pySim/commands.py", line 51, in read_binary
> >>    r = self.select_file(ef)
> >>  File "/home/wirelesss/net/pysim/pySim/commands.py", line 44, in select_file
> >>    data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
> >>  File "/home/wirelesss/net/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
> >>    raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
> >> RuntimeError: SW match failed ! Expected 9000 and got 6b00.
> 
> I think master has issues with the GR1 card, e.g. try e9e5ecbe3068dae7e6e0959f22ed1855911dc892
> 
> holger

I can confirm: current pySim master fails for sysmosim-gr1.

My local pySim clone was still on the revision before that, which works
like a charm. As soon as I pulled the latest master, I got the same error
as Ivo, also confirmed by Max.

It looks like we should revert this commit, and/or make it configurable by a
command line option that is off by default, or maybe depend this on the SIM type in use?


commit 8c1b33c439fef423c3536e9243035722c52aba4c
Refs: {origin/HEAD}, {origin/master}, {origin/zecke/tmp}
Author:     Jan Balke <jan at corenetdynamics.com>
AuthorDate: Mon Jan 26 11:18:28 2015 +0100
Commit:     Harald Welte <laforge at gnumonks.org>
CommitDate: Thu Aug 20 13:32:56 2015 +0200

    Do not return the FCI information while selecting a file

    The sysmoUSIM-SJS1 card does not support returning the FCI
    information.
    Plus, the FCI information are not used anyway.
---
 pySim/commands.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pySim/commands.py b/pySim/commands.py
index cb72a11..721b3d4 100644
--- a/pySim/commands.py
+++ b/pySim/commands.py
@@ -41,7 +41,7 @@ class SimCardCommands(object):
        def select_file(self, dir_list):
                rv = []
                for i in dir_list:
-                       data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000002" + i)
+                       data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
                        rv.append(data)
                return rv


-- 
- 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/20161018/1a6f8d6b/attachment.bin>

From msuraev at sysmocom.de  Tue Oct 18 10:46:01 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 18 Oct 2016 12:46:01 +0200
Subject: new warnings because of ctrl constify
In-Reply-To: <20161018001539.GA10319@my.box>
References: <20161018001539.GA10319@my.box>
Message-ID: <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>

Hi.

I think it's better to fix those warnings instead of rolling back
commit. It was added because without it there were plenty of warnings in
other places so overall we won't decrease number of warnings - we'll
just shift them from one place to another. Besides if we follow that
logic we have to rollback f45334be29016a36594aacc07c90e262e4994525 for
example.

Regarding the potential fix - it pretty-much boild down to interaction
between strtok_r() and talloc(). The obvious way would be to
talloc_strdup() string before passing it to 1st call to strtok_r(). The
potential problem is that strtok_r() changes it's argument. So the
questions are:
- do we expect that strtok_r() changes to 1st argument? If so - what
kind of changes are expected?
- what does strtok_r() do with memory? When it is safe to remove
duplicated string passed to it?

On 10/18/2016 02:15 AM, Neels Hofmeyr wrote:
> Presumably after this libosmocore commit, I get scores of new warnings (see
> below) when compiling openbsc:
>
> commit ed9d6da5df98538adc70aa03cb569eb9505d04b6
> Author:     Max <msuraev at sysmocom.de>
> AuthorDate: Tue Oct 11 15:20:28 2016 +0200
>
>     Constify ctrl_cmd struct fields where appropriate
>
>
>
> Some of these can be fixed by constifying the functions as well, but
> talloc_free() of a const char * looks really wrong?
>
> Please follow up on this or revert the commit... constifying is good, but
> having twice the amount of warnings means twice the reading effort during
> development cycles.
>
> I would most prefer a revert now and come back as soon as no new warnings are
> introduced; ymmv...
>
>
> In file included from /usr/local/include/osmocom/core/talloc.h:4:0,
>                  from ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:22:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?bsc_nat_handle_ctrlif_msg?:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:131:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
>     talloc_free(cmd->variable);
>                 ^
> /usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
>  int _talloc_free(void *ptr, const char *location);
>      ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:143:34: warning: passing argument 2 of ?bsc_get_pending? discards ?const? qualifier from pointer target type
>    pending = bsc_get_pending(bsc, cmd->id);
>                                   ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:86:29: note: expected ?char *? but argument is of type ?const char *?
>  static struct bsc_cmd_list *bsc_get_pending(struct bsc_connection *bsc, char *id_str)
>                              ^
> ../../../src/osmo-bsc_nat/bsc_ussd.c: In function ?bsc_ussd_check?:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?forward_to_bsc?:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:228:31: warning: passing argument 1 of ?extract_bsc_nr_variable? discards ?const? qualifier from pointer target type
>   if (!extract_bsc_nr_variable(cmd->variable, &nr, &bsc_variable)) {
>                                ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:198:12: note: expected ?char *? but argument is of type ?const char *?
>  static int extract_bsc_nr_variable(char *variable, unsigned int *nr, char **bsc_variable)
>             ^
> In file included from /usr/local/include/osmocom/core/talloc.h:4:0,
>                  from ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:22:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:259:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
>     talloc_free(bsc_cmd->id);
>                 ^
> /usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
>  int _talloc_free(void *ptr, const char *location);
>      ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:266:16: warning: passing argument 1 of ?_talloc_free? discards ?const? qualifier from pointer target type
>     talloc_free(bsc_cmd->variable);
>                 ^
> /usr/include/talloc.h:227:5: note: expected ?void *? but argument is of type ?const char *?
>  int _talloc_free(void *ptr, const char *location);
>      ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c: In function ?extract_bsc_cfg_variable?:
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:323:31: warning: passing argument 1 of ?extract_bsc_nr_variable? discards ?const? qualifier from pointer target type
>   if (!extract_bsc_nr_variable(cmd->variable, &nr, bsc_variable)) {
>                                ^
> ../../../src/osmo-bsc_nat/bsc_nat_ctrl.c:198:12: note: expected ?char *? but argument is of type ?const char *?
>  static int extract_bsc_nr_variable(char *variable, unsigned int *nr, char **bsc_variable)
>             ^
>
>
>
>

-- 
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 sebastian.stumpf87 at googlemail.com  Tue Oct 18 17:32:03 2016
From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf)
Date: Tue, 18 Oct 2016 19:32:03 +0200
Subject: Osmo-bts/Osmocom-bb virtual layer 1
Message-ID: <CALFVOed+7r3bhRPAGu_04a0ufjonBNrqbFB6+w6qC2+HenVywQ@mail.gmail.com>

Hi,

I further implemented the base of the virtual layer with the purpose
of replacing the um-air interface with a multicast-socket solution.
This has been started by Harald Welte some time ago in the Osmobts -
laforge/virt-bts branch.
As I was not really confident enough to create an official new branch
before someone had a look on what I did, so I developed in copies of
the osmocom-bb and osmo-bts projects on my github-page
(https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and
https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts).
If someone finds to time to have a look into them (structure, path,
implementation) and give me feedback about it, I would be glad :).
Please use the following config files that i have tested:
 - https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtual.cfg
 - https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtual.cfg
- https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mobile.cfg

What works:
BTS:
 - downlink over gsmtap and a multicast socket
 - OML and RSL on abis properly established and seems to work
 - virtual-um connection establishment
Osmocom-bb:
 - virtual-um -- l23 app connection establishment (bridging osmocon,
no serial link needed)
 - BCCH downlink handling and forwarding to l23 app
 - handling of some l1ctl requests from l23 (e.g. power management had
to be mocked, so l23 gets a response and is satisfied)

What not:
BTS:
 - missing uplink handling
Osmocom-bb
 - missing uplink routines (RACH, TCH, dedicated channels)
 - handlers for l23 requests only partially implemented (missing TCH, RACH, ...

I a currently a bit overwhelmed by the mass of messages exchanged
between l23-app (used mobile, btw.) and the virtual-um and hanging
because mobile gets a sync timeout.

I am looking forward to hear from you :).

Sebastian Stumpf


From tom at tsou.cc  Tue Oct 18 18:15:34 2016
From: tom at tsou.cc (Tom Tsou)
Date: Tue, 18 Oct 2016 11:15:34 -0700
Subject: osmo-trx and gpsdo
In-Reply-To: <e07e2147-e0f7-c81e-1819-4baeab1d1522@sysmocom.de>
References: <cb36d0be-080c-ff31-9ea6-08ffd6e6c0f9@sysmocom.de>
 <54a67f30-46b2-447a-0d6e-a74a9393bc39@sysmocom.de>
 <CAATyM+Yx=qqLCJdSXy64WB_9AKO3cXBo=Dnrn04WO1EGtaBiBQ@mail.gmail.com>
 <CAATyM+aERRKmcUHOgYqsx9jPPcKiXBTvkkRo4e4vXXFfa-gezA@mail.gmail.com>
 <e07e2147-e0f7-c81e-1819-4baeab1d1522@sysmocom.de>
Message-ID: <CAATyM+b=z-g0qSUmSwKrVmPcjHO2Hb_LUr_3ZHqD1nKAppfHcw@mail.gmail.com>

On Tue, Oct 18, 2016 at 1:06 AM, Max <msuraev at sysmocom.de> wrote:
> How do I check that? Also, should adding/removing GPS antennae make any
> difference?

The GPSDO module is an add-on component about that is about 2cm
square. It mounts in the headers directly behind the GPS antenna port.
If the area is empty, there is no GPSDO. GPS antennae will only have
an effect if the module is populated.

  https://www.ettus.com/product/details/GPSDO-TCXO-MODULE

If the GPSDO is not present, but is selected on the osmo-trx command
line anyways, the proper action is to exit gracefully or continue
without using the non-existent GPSDO; error logging should be output
in both cases. Currently, UHD crashes in this event, which is clearly
a bug.

 -TT


From laforge at gnumonks.org  Wed Oct 19 07:14:43 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 19 Oct 2016 09:14:43 +0200
Subject: Osmo-bts/Osmocom-bb virtual layer 1
In-Reply-To: <CALFVOed+7r3bhRPAGu_04a0ufjonBNrqbFB6+w6qC2+HenVywQ@mail.gmail.com>
References: <CALFVOed+7r3bhRPAGu_04a0ufjonBNrqbFB6+w6qC2+HenVywQ@mail.gmail.com>
Message-ID: <20161019071443.ry3dp7offty2umrp@nataraja>

Hi Sebastian,

thanks a lot for working on this and for requesting feedback.

It's quite a lot of code to review, so it might take a bit until you
hear from me.  But I definitely want to help.

If you menawhile have specific questions, please feel free to post them
here and I'll try my best to respond, at least if nobody else respnds
before me ;)

Regards,
	Harald

> I a currently a bit overwhelmed by the mass of messages exchanged
> between l23-app (used mobile, btw.) 

it might make sense to start with something more simple than a
fully-blown 'mobile' program.  Take the L1CTL primitives step by step,
one at a time.

-- 
- 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 martin.openbsc at olifantasia.com  Wed Oct 19 11:40:01 2016
From: martin.openbsc at olifantasia.com (Martin Dudok van Heel)
Date: Wed, 19 Oct 2016 13:40:01 +0200
Subject: pysim Fakemagicsim problem + workaround Fwd: SIM Card Reader Problem!!
Message-ID: <58075B91.2040900@olifantasia.com>

Second try. (I already sent this mail yesterday, but it did not appear 
in the mailinglist. I do not know why. Maybe because I attached a file 
(a patch))

Hi all,

This is my first post to the OpenBSC mailinglist.

I had a problem with the latest pysim version giving errors while trying 
to program 2G (Fake)MagicSIM cards.
This had worked fine in the past with an older release from 2011.
I tried al lot of versions in between.
I was finally able to narrow it down to the commit that broke 
compatibility with (fake)magicsim:

http://cgit.osmocom.org/pysim/commit/pySim/commands.py?id=8c1b33c439fef423c3536e9243035722c52aba4c 

The comment with this comit is: "Do not return the FCI information while
selecting a file
The sysmoUSIM-SJS1 card does not support returning the FCI information.
Plus, the FCI information are not used anyway."

If I revert the change with attached patch, it works again.

But it may break sysmoUSIM-SJS1 compatibility.
I am not sure on how to test whether the programming of sysmoUSIM-SJS1 
still works fine and if the SIMS themselves then will still work as 
expected with OpenBSC or OpenBTS or OpenAirinterface.

If the code needs to stay in for sysmoUSIM-SJS1 then we probably need 
somehing like the pseudocode below:

if carttype is fakemagicsim:
    "a4000002"
elif  cardtype is sysmoUSIM-SJS1:
    "a4000C02"
else:
    #What should be the default for the other cards?

Or is there another solution?

With best regards,

Martin Dudok van Heel


This is the patch inline (attaching it as a file, blocked my email from 
going through)
mdvh_pysim_make_fakesim_work_again_patch_2016081201.diff

diff --git a/pySim/commands.py b/pySim/commands.py
index 721b3d4..b7fb77f 100644
--- a/pySim/commands.py
+++ b/pySim/commands.py
@@ -41,7 +41,7 @@ class SimCardCommands(object):
         def select_file(self, dir_list):
                 rv = []
                 for i in dir_list:
-                       data, sw = 
self._tp.send_apdu_checksw(self.cla_byte + "a4000C02" + i)
+                       data, sw = 
self._tp.send_apdu_checksw(self.cla_byte + "a4000002" + i)
                         rv.append(data)
                 return rv


On 12-08-16 09:50, Holger Freyther wrote:
>> On 12 Aug 2016, at 09:18, Rene Groothuis wrote:
>>
>> Hello,
> Hi!
>
>
>> I?m still having problems, sorry to report this. Below the log file 
>> of different combinations:
>>
>
>> I?ve used different (same model) SIM cards. I?ve reinstated the USB 
>> reader. Tried in different USB ports. No Luck.
>>
>> What am I doing wrong, can you please help?
>>
>>
> Sysmocom sold the last 16in1 magicsim in 2012? Did you buy these cards 
> from us? Maybe this specific one is just broken? Maybe try an older 
> version of pySIM? E.g. maybe some of the patches required for the 
> sysmoUSIM-SJS1 broke magicsim support?
>
> In the future you could consider getting the sysmoUSIM-SJS1 from us, 
> they are of way higher quality than the Chinese (GRcard, magicsim, 
> etc.) ones. For emergencies like these it might make sense for you to 
> get a support contract from sysmocom as well.
>
> good luck
>
>     holger
>
>


From nhofmeyr at sysmocom.de  Wed Oct 19 12:02:31 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 19 Oct 2016 14:02:31 +0200
Subject: new warnings because of ctrl constify
In-Reply-To: <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>
References: <20161018001539.GA10319@my.box>
 <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>
Message-ID: <20161019120231.GA1498@my.box>

On Tue, Oct 18, 2016 at 12:46:01PM +0200, Max wrote:
> Hi.
> 
> I think it's better to fix those warnings instead of rolling back
> commit.

I totally agree in principle. The point is, this commit added a *huge* amount
of warnings = a large amount of time loss to every compilation cycle. I would
prefer if you *first* fix the fallout and *then* apply things like this.

This is such that I would invest time in somehow recording what warnings I have
already seen and only showing the changes in warnings; but the time is better
spent by not having such a large amount of warnings, and not forget about them.

So, where is your warning squelching patch right now, please?
Thanks for your understanding...

~Neels

-------------- 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/20161019/02cfcb30/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Oct 19 12:12:02 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 19 Oct 2016 14:12:02 +0200
Subject: pysim Fakemagicsim problem + workaround Fwd: SIM Card Reader
 Problem!!
In-Reply-To: <58075B91.2040900@olifantasia.com>
References: <58075B91.2040900@olifantasia.com>
Message-ID: <20161019121202.GB1498@my.box>

Dear Martin,

thanks for your report. The failure is known and we've actually posted about
this just the past two days.

I have now created an issue for this: https://osmocom.org/issues/1828

~Neels


-- 
- 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/20161019/fd963f14/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Oct 19 12:12:23 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 19 Oct 2016 14:12:23 +0200
Subject: pySim current master fails for sysmosim-gr1
In-Reply-To: <20161018095734.GA1521@ass40.sysmocom.de>
References: <379defbc-47a2-11f2-d1ff-2c7dd636e063@sysmocom.de>
 <EE813191-66A5-4FDA-91F3-6A4F4F08C478@freyther.de>
 <20161018095734.GA1521@ass40.sysmocom.de>
Message-ID: <20161019121223.GC1498@my.box>

--> https://osmocom.org/issues/1828

On Tue, Oct 18, 2016 at 11:57:34AM +0200, Neels Hofmeyr wrote:
> > >> RuntimeError: SW match failed ! Expected 9000 and got 6b00.
-------------- 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/20161019/c96dfb17/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Oct 19 12:16:11 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 19 Oct 2016 14:16:11 +0200
Subject: [scan-admin@coverity.com: New Defects reported by Coverity Scan for
 Osmocom]
Message-ID: <20161019121611.GD1498@my.box>


Hi,

Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan.

2 new defect(s) introduced to Osmocom found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 150437:  Insecure data handling  (TAINTED_SCALAR)
/source-Osmocom/libosmo-abis/src/input/misdn.c: 462 in handle_ts_raw_read()


________________________________________________________________________________________________________
*** CID 150437:  Insecure data handling  (TAINTED_SCALAR)
/source-Osmocom/libosmo-abis/src/input/misdn.c: 462 in handle_ts_raw_read()
456     		DEBUGP(DLMIB, "<= RAW CHAN len = %d, prim(0x%x) id(0x%x): %s\n",
457     			ret, hh->prim, hh->id,
458     			get_value_string(prim_names, hh->prim));
459     
460     	switch (hh->prim) {
461     	case PH_DATA_IND:
>>>     CID 150437:  Insecure data handling  (TAINTED_SCALAR)
>>>     Assigning: "msg->l2h" = "msg->data + 8UL". Both are now tainted.
462     		msg->l2h = msg->data + MISDN_HEADER_LEN;
463     		DEBUGP(DLMIB, "RAW CHAN RX: %s\n",
464     			osmo_hexdump(msgb_l2(msg), ret - MISDN_HEADER_LEN));
465     		/* the number of bytes received indicates that data to send */
466     		handle_ts_raw_write(bfd, msgb_l2len(msg));
467     		return e1inp_rx_ts(e1i_ts, msg, 0, 0);

** CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
/source-Osmocom/osmo-pcu/src/tbf_dl.cpp: 310 in ()


________________________________________________________________________________________________________
*** CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
/source-Osmocom/osmo-pcu/src/tbf_dl.cpp: 310 in ()
304     		msgb_free(msg);
305     		bts->llc_dropped_frame();
306     		continue;
307     	}
308     
309     	if (frames) {
>>>     CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
>>>     argument is incompatible with corresponding format string conversion
310     		LOGP(DRLCMACDL, LOGL_NOTICE, "%s Discarding LLC PDU "
311     			"because lifetime limit reached, "
312     			"count=%u new_queue_size=%zu\n",
313     			tbf_name(this), frames, llc_queue_size());
314     		if (frames > 0xff)
315     			frames = 0xff;


-------------- 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/20161019/ac95ae24/attachment.bin>

From msuraev at sysmocom.de  Wed Oct 19 12:56:05 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 19 Oct 2016 14:56:05 +0200
Subject: [scan-admin@coverity.com: New Defects reported by Coverity Scan
 for Osmocom]
In-Reply-To: <20161019121611.GD1498@my.box>
References: <20161019121611.GD1498@my.box>
Message-ID: <01acb0f7-1673-82a8-50e8-56ddf83e733b@sysmocom.de>

Hi.

I appreciate your intention on making code better but do you really
think that re-posting those emails worth your time? I think all the devs
who could fix it are receiving it directly from Coverity already, and
for others it just creates additional noise in ML.

I also do not think that there's any urgency with those - we have about
500 of unfixed defects detected by Coverity so far, +-2 do not make big
difference compared to that amount.

On 10/19/2016 02:16 PM, Neels Hofmeyr wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan.
>
> 2 new defect(s) introduced to Osmocom found with Coverity Scan.
> 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
>
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
>
>
> ** CID 150437:  Insecure data handling  (TAINTED_SCALAR)
> /source-Osmocom/libosmo-abis/src/input/misdn.c: 462 in handle_ts_raw_read()
>
>
> ________________________________________________________________________________________________________
> *** CID 150437:  Insecure data handling  (TAINTED_SCALAR)
> /source-Osmocom/libosmo-abis/src/input/misdn.c: 462 in handle_ts_raw_read()
> 456     		DEBUGP(DLMIB, "<= RAW CHAN len = %d, prim(0x%x) id(0x%x): %s\n",
> 457     			ret, hh->prim, hh->id,
> 458     			get_value_string(prim_names, hh->prim));
> 459     
> 460     	switch (hh->prim) {
> 461     	case PH_DATA_IND:
>>>>     CID 150437:  Insecure data handling  (TAINTED_SCALAR)
>>>>     Assigning: "msg->l2h" = "msg->data + 8UL". Both are now tainted.
> 462     		msg->l2h = msg->data + MISDN_HEADER_LEN;
> 463     		DEBUGP(DLMIB, "RAW CHAN RX: %s\n",
> 464     			osmo_hexdump(msgb_l2(msg), ret - MISDN_HEADER_LEN));
> 465     		/* the number of bytes received indicates that data to send */
> 466     		handle_ts_raw_write(bfd, msgb_l2len(msg));
> 467     		return e1inp_rx_ts(e1i_ts, msg, 0, 0);
>
> ** CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
> /source-Osmocom/osmo-pcu/src/tbf_dl.cpp: 310 in ()
>
>
> ________________________________________________________________________________________________________
> *** CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
> /source-Osmocom/osmo-pcu/src/tbf_dl.cpp: 310 in ()
> 304     		msgb_free(msg);
> 305     		bts->llc_dropped_frame();
> 306     		continue;
> 307     	}
> 308     
> 309     	if (frames) {
>>>>     CID 150436:  API usage errors  (PW.PRINTF_ARG_MISMATCH)
>>>>     argument is incompatible with corresponding format string conversion
> 310     		LOGP(DRLCMACDL, LOGL_NOTICE, "%s Discarding LLC PDU "
> 311     			"because lifetime limit reached, "
> 312     			"count=%u new_queue_size=%zu\n",
> 313     			tbf_name(this), frames, llc_queue_size());
> 314     		if (frames > 0xff)
> 315     			frames = 0xff;
>
>

-- 
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 19 13:03:04 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 19 Oct 2016 15:03:04 +0200
Subject: new warnings because of ctrl constify
In-Reply-To: <20161019120231.GA1498@my.box>
References: <20161018001539.GA10319@my.box>
 <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>
 <20161019120231.GA1498@my.box>
Message-ID: <bbf922ff-a542-1836-9a04-168ff8682dc6@sysmocom.de>

I've made ticket for this: https://projects.osmocom.org/issues/1829


On 10/19/2016 02:02 PM, Neels Hofmeyr wrote:
> On Tue, Oct 18, 2016 at 12:46:01PM +0200, Max wrote:
>> Hi.
>>
>> I think it's better to fix those warnings instead of rolling back
>> commit.
> I totally agree in principle. The point is, this commit added a *huge* amount
> of warnings = a large amount of time loss to every compilation cycle. I would
> prefer if you *first* fix the fallout and *then* apply things like this.
>
> This is such that I would invest time in somehow recording what warnings I have
> already seen and only showing the changes in warnings; but the time is better
> spent by not having such a large amount of warnings, and not forget about them.
>
> So, where is your warning squelching patch right now, please?
> Thanks for your understanding...
>
> ~Neels
>

-- 
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 20 11:11:10 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 20 Oct 2016 13:11:10 +0200
Subject: [scan-admin@coverity.com: New Defects reported by Coverity Scan
 for Osmocom]
In-Reply-To: <01acb0f7-1673-82a8-50e8-56ddf83e733b@sysmocom.de>
References: <20161019121611.GD1498@my.box>
 <01acb0f7-1673-82a8-50e8-56ddf83e733b@sysmocom.de>
Message-ID: <20161020111110.GA1340@my.box>

On Wed, Oct 19, 2016 at 02:56:05PM +0200, Max wrote:
> I think all the devs who could fix it are receiving it directly from Coverity
> already

My impression was that we don't. Do we all see these mails?
Reading and trying to understand takes me time, the forwarding doesn't.
And this mail here takes me time ;)

> for others it just creates additional noise in ML.

IMHO justified: on-topic and low volume, easy to skip if you're not interested.
But if anyone else complains as well I'll be happy to cease it.

Of course we should also look at the million coverity warnings that aren't new
from time to time ;)

~Neels

-------------- 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/20161020/1d45686d/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Oct 20 11:35:05 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 20 Oct 2016 13:35:05 +0200
Subject: new warnings because of ctrl constify
In-Reply-To: <bbf922ff-a542-1836-9a04-168ff8682dc6@sysmocom.de>
References: <20161018001539.GA10319@my.box>
 <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>
 <20161019120231.GA1498@my.box>
 <bbf922ff-a542-1836-9a04-168ff8682dc6@sysmocom.de>
Message-ID: <20161020113505.GB1340@my.box>

On Wed, Oct 19, 2016 at 03:03:04PM +0200, Max wrote:
> I've made ticket for this: https://projects.osmocom.org/issues/1829

So you would like to first write unit tests and so on until these warnings will
go away. How urgently will you pursue this? Are you actively working on it?

I will locally revert the constify patch to avoid the warnings flood. Which
adds the need for rebase for every pull in libosmocore. I have some of those
already related to the 3G branches: it's cumbersome.

Can we please commit the revert on master and re-commit the constify when
OS#1829 is resolved?

~Neels

-------------- 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/20161020/45c3be21/attachment.bin>

From msuraev at sysmocom.de  Thu Oct 20 11:41:54 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 20 Oct 2016 13:41:54 +0200
Subject: new warnings because of ctrl constify
In-Reply-To: <20161020113505.GB1340@my.box>
References: <20161018001539.GA10319@my.box>
 <e6c15dcf-cf03-42e9-eb43-9a13684a5f02@sysmocom.de>
 <20161019120231.GA1498@my.box>
 <bbf922ff-a542-1836-9a04-168ff8682dc6@sysmocom.de>
 <20161020113505.GB1340@my.box>
Message-ID: <1a67bd4c-6b19-75fd-c346-1873956db558@sysmocom.de>

There are other things like DTX and PTCCH which prevent me from working
on this right now. As I've explained in the ticket I don't think that
reverting this commit is urgent but feel free to add your comments to
the ticket, send revert patch to gerrit, raise ticket urgency with
Harald etc. etc.


On 10/20/2016 01:35 PM, Neels Hofmeyr wrote:
> On Wed, Oct 19, 2016 at 03:03:04PM +0200, Max wrote:
>> I've made ticket for this: https://projects.osmocom.org/issues/1829
> So you would like to first write unit tests and so on until these warnings will
> go away. How urgently will you pursue this? Are you actively working on it?
>
> I will locally revert the constify patch to avoid the warnings flood. Which
> adds the need for rebase for every pull in libosmocore. I have some of those
> already related to the 3G branches: it's cumbersome.
>
> Can we please commit the revert on master and re-commit the constify when
> OS#1829 is resolved?
>
> ~Neels
>

-- 
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 20 13:33:30 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 20 Oct 2016 15:33:30 +0200
Subject: [scan-admin@coverity.com: New Defects reported by Coverity Scan
 for Osmocom]
In-Reply-To: <20161020111110.GA1340@my.box>
References: <20161019121611.GD1498@my.box>
 <01acb0f7-1673-82a8-50e8-56ddf83e733b@sysmocom.de>
 <20161020111110.GA1340@my.box>
Message-ID: <20161020133330.GD1340@my.box>

On Thu, Oct 20, 2016 at 01:11:10PM +0200, Neels Hofmeyr wrote:
> On Wed, Oct 19, 2016 at 02:56:05PM +0200, Max wrote:
> > I think all the devs who could fix it are receiving it directly from Coverity
> > already
> 
> My impression was that we don't. Do we all see these mails?

Ah, I see now the list of members on the Osmocom coverity project, quite
exhaustive -- even some inactive members are in there. I guess you're right,
then. Will only send in case I have comments in the future.

~Neels

-------------- 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/20161020/f0dfe012/attachment.bin>

From 246tnt at gmail.com  Fri Oct 21 13:31:46 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 21 Oct 2016 15:31:46 +0200
Subject: Review of conv_gen changes
In-Reply-To: <20161012100038.iepgfpyx4l6qaco4@nataraja>
References: <20161012100038.iepgfpyx4l6qaco4@nataraja>
Message-ID: <CAHL+j0_3h71z914AVFZNDwjMWZzW4bjkF-wzVEfYYyq3Y=JpMw@mail.gmail.com>

Hi,

> I was hoping that you could review the conv_gen.py and related changes
> that Vadim has been working on. I don't feel familiar enough with the
> code (and not morally authorized to merge such significant canges) to
> your code.
>
> The code is at https://gerrit.osmocom.org/#/c/828/5 as well as related
> changes like https://gerrit.osmocom.org/#/c/829/4

Looking at those now ...

Cheers,

   Sylvain


From laforge at gnumonks.org  Sat Oct 22 18:30:28 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 22 Oct 2016 20:30:28 +0200
Subject: [scan-admin@coverity.com: New Defects reported by Coverity Scan
 for Osmocom]
In-Reply-To: <20161020133330.GD1340@my.box>
References: <20161019121611.GD1498@my.box>
 <01acb0f7-1673-82a8-50e8-56ddf83e733b@sysmocom.de>
 <20161020111110.GA1340@my.box> <20161020133330.GD1340@my.box>
Message-ID: <20161022183028.zad2losvzkqbqqp7@nataraja>

On Thu, Oct 20, 2016 at 03:33:30PM +0200, Neels Hofmeyr wrote:
> > My impression was that we don't. Do we all see these mails?
> 
> Ah, I see now the list of members on the Osmocom coverity project, quite
> exhaustive -- even some inactive members are in there. I guess you're right,
> then. Will only send in case I have comments in the future.

It might make sense to simply have the reports sent to this mailing list
instead of a number of recipients privately.  What do you think?

It's not that we're trying to hide bugs in our code.  For sure there are
plenty...

-- 
- 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 24 02:00:41 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 24 Oct 2016 04:00:41 +0200
Subject: plz fix osmo-gsm-manuals/OpenBTS Makefile
Message-ID: <20161024020041.GA25819@my.box>

Hi,

the below commit drops the osmo-bts-abis.pdf from the Makefile!
Currently the Abis manual is thus missing completely.
Please fix... thx!

~Neels


commit 05f5adbe837f2cbfb9301cdb8c9b454ca0bfc825
Author: Alexander Couzens <lynxis at fe80.eu>
Date:   Fri Oct 14 16:56:42 2016 +0200

    OsmoBTS: add vty reference documentation
    
    Including the required changes of the Makefile which is now simliar
    as the other projects Makefile's.
    Based on: OsmoBTS 0.3.0.283-f869
    
    Change-Id: Id7362ce1c584b1926330b93770d68453e091c71c


-- 
- 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/20161024/a48ce9ff/attachment.bin>

From msuraev at sysmocom.de  Mon Oct 24 16:51:58 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 24 Oct 2016 18:51:58 +0200
Subject: osmo-trx jenkins
Message-ID: <2ea481fb-0042-815c-6e1c-2e25eb0ee890@sysmocom.de>

HI.

A little heads up: uhd version in jenkins building osmo-trx should be
updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
by jenkins.

-- 
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  Mon Oct 24 23:52:25 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 25 Oct 2016 01:52:25 +0200
Subject: osmo-trx jenkins
In-Reply-To: <2ea481fb-0042-815c-6e1c-2e25eb0ee890@sysmocom.de>
References: <2ea481fb-0042-815c-6e1c-2e25eb0ee890@sysmocom.de>
Message-ID: <20161024235225.GA3707@my.box>

On Mon, Oct 24, 2016 at 06:51:58PM +0200, Max wrote:
> HI.
> 
> A little heads up: uhd version in jenkins building osmo-trx should be
> updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
> by jenkins.

Is it really necessary to require UHD 3.9 as minimum? This means that pretty
much all osmo-trx users will have to build UHD from source at this point; there
generally seem to be no UHD packages available that are recent enough.

If it's necessary, then let's go ahead, but just asking whether it's a
nice-to-have or a real hard requirement that all users *must* satisfy to be
able to use osmo-trx.

Building UHD 3.9.5 from source on the build slave now.

~Neels


-- 
- 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/20161025/002e90fd/attachment.bin>

From tom at tsou.cc  Tue Oct 25 00:21:40 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 24 Oct 2016 17:21:40 -0700
Subject: osmo-trx jenkins
In-Reply-To: <20161024235225.GA3707@my.box>
References: <2ea481fb-0042-815c-6e1c-2e25eb0ee890@sysmocom.de>
 <20161024235225.GA3707@my.box>
Message-ID: <CAATyM+bRJ7x4PbqUi=rre-WknqPGcYuNd=Tox2VFko46XPKAwQ@mail.gmail.com>

On Mon, Oct 24, 2016 at 4:52 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> On Mon, Oct 24, 2016 at 06:51:58PM +0200, Max wrote:
>> A little heads up: uhd version in jenkins building osmo-trx should be
>> updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
>> by jenkins.
>
> Is it really necessary to require UHD 3.9 as minimum? This means that pretty
> much all osmo-trx users will have to build UHD from source at this point; there
> generally seem to be no UHD packages available that are recent enough.

UHD versions prior to 3.9 are no longer actively maintained. The 3.9
series of releases is the current 'long term support' version.

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-August/021306.html

PPA packages are available.

https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts

> If it's necessary, then let's go ahead, but just asking whether it's a
> nice-to-have or a real hard requirement that all users *must* satisfy to be
> able to use osmo-trx.

It's a hard requirement for some features - namely multi-carrier BTS.
On the code level, we currently need to add additional ifdef's in
order to support older UHD API and behavioral version dependencies.

I really don't like the idea of forcing users up to UHD 3.9, but for
code and stability reasons that is the strongly recommended version
right now.

  -TT


From nhofmeyr at sysmocom.de  Tue Oct 25 01:08:40 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 25 Oct 2016 03:08:40 +0200
Subject: plz fix osmo-gsm-manuals/OpenBTS Makefile
In-Reply-To: <20161024020041.GA25819@my.box>
References: <20161024020041.GA25819@my.box>
Message-ID: <20161025010840.GA10981@my.box>

...it's a tiny amount of work to get rid of a gigantic error, I'd appreciate if
you could get this out of the way immediately instead of postponing, which
tends to mean that I will end up fixing it for you (which I prefer not to).

IMHO if one of us introduces a bug on master, the first thing we should do is
get rid of it again, if needs be with a quick revert and later follow-up.

The mails we've sent back and forth on this by now hardly match the microscopic
effort of fixing the actual problem.

Thanks for understanding my perspective on this :)

~Neels


On Mon, Oct 24, 2016 at 04:00:41AM +0200, Neels Hofmeyr wrote:
> Hi,
> 
> the below commit drops the osmo-bts-abis.pdf from the Makefile!
> Currently the Abis manual is thus missing completely.
> Please fix... thx!
> 
> ~Neels
> 
> 
> commit 05f5adbe837f2cbfb9301cdb8c9b454ca0bfc825
> Author: Alexander Couzens <lynxis at fe80.eu>
> Date:   Fri Oct 14 16:56:42 2016 +0200
> 
>     OsmoBTS: add vty reference documentation
>     
>     Including the required changes of the Makefile which is now simliar
>     as the other projects Makefile's.
>     Based on: OsmoBTS 0.3.0.283-f869
>     
>     Change-Id: Id7362ce1c584b1926330b93770d68453e091c71c
-------------- 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/20161025/864d1d2c/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Oct 25 14:37:17 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 25 Oct 2016 16:37:17 +0200
Subject: plz fix osmo-gsm-manuals/OpenBTS Makefile
In-Reply-To: <20161025010840.GA10981@my.box>
References: <20161024020041.GA25819@my.box>
 <20161025010840.GA10981@my.box>
Message-ID: <20161025143717.GA1978@my.box>

Excellent, thanks for reacting so quickly. The OsmoBTS Abis manual is back.

~Neels


-- 
- 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/20161025/b79c9b88/attachment.bin>

From msuraev at sysmocom.de  Tue Oct 25 16:20:16 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 25 Oct 2016 18:20:16 +0200
Subject: asan for libosmo*
Message-ID: <90eee2b0-d17e-29e3-b2c8-b33ea73941ea@sysmocom.de>

Hi.

Address Sanitizer is currently enabled for libosmocore jenkins build
(which is really great, thanks al being involved!) but not for other
libraries. According to recent checks in
http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ asan only
fails for OpenBSC so it seems like it can be enabled for other libosmo*
libraries as well.

What do you think?

-- 
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  Tue Oct 25 23:16:32 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 26 Oct 2016 01:16:32 +0200
Subject: asan for libosmo*
In-Reply-To: <90eee2b0-d17e-29e3-b2c8-b33ea73941ea@sysmocom.de>
References: <90eee2b0-d17e-29e3-b2c8-b33ea73941ea@sysmocom.de>
Message-ID: <20161025231632.GB1978@my.box>

On Tue, Oct 25, 2016 at 06:20:16PM +0200, Max wrote:
> Hi.
> 
> Address Sanitizer is currently enabled for libosmocore jenkins build
> (which is really great, thanks al being involved!) but not for other
> libraries. According to recent checks in
> http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ asan only
> fails for OpenBSC so it seems like it can be enabled for other libosmo*
> libraries as well.
> 
> What do you think?

I have it on my todo list, first wanted to get libosmocore through as a
confirmation that using a ./configure switch is acceptable.

One point though might be build time: it is conceivable that an ASAN build
hides bugs that a normal build exhibits, so we would preferably build both with
and without ASAN in our jenkins build jobs. I'm not entirely sure whether all
dependencies need to be built with ASAN or only the final linking of a binary
is enough. For example building openbsc with all of its dependencies once with
and once without ASAN would double our build matrix, yet again. In libosmocore,
we once run 'make check' with ASAN and then 'make distcheck' without ASAN,
which completes fairly quickly. We'll have to see what ASAN means for the other
projects' gerrit build jobs.

For starters, it would be great to fix the ASAN failure seen in
https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
Also on my todo-list, but let's see who catches it first :)

~Neels


-- 
- 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/20161026/fb2e30f1/attachment.bin>

From msuraev at sysmocom.de  Wed Oct 26 08:03:06 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 26 Oct 2016 10:03:06 +0200
Subject: asan for libosmo*
In-Reply-To: <20161025231632.GB1978@my.box>
References: <90eee2b0-d17e-29e3-b2c8-b33ea73941ea@sysmocom.de>
 <20161025231632.GB1978@my.box>
Message-ID: <150e6450-83e3-13fd-65ff-cc46d292e20e@sysmocom.de>

Well, we can already enable asan for all the libraries (hence the $subj)
and get back to openbsc once the current failures are fixed.

My guess is that all the dependencies got to build using asan as well
but I don't think it will make much differences in build time in case of
libraries.


On 10/26/2016 01:16 AM, Neels Hofmeyr wrote:
> On Tue, Oct 25, 2016 at 06:20:16PM +0200, Max wrote:
>> Hi.
>>
>> Address Sanitizer is currently enabled for libosmocore jenkins build
>> (which is really great, thanks al being involved!) but not for other
>> libraries. According to recent checks in
>> http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ asan only
>> fails for OpenBSC so it seems like it can be enabled for other libosmo*
>> libraries as well.
>>
>> What do you think?
> I have it on my todo list, first wanted to get libosmocore through as a
> confirmation that using a ./configure switch is acceptable.
>
> One point though might be build time: it is conceivable that an ASAN build
> hides bugs that a normal build exhibits, so we would preferably build both with
> and without ASAN in our jenkins build jobs. I'm not entirely sure whether all
> dependencies need to be built with ASAN or only the final linking of a binary
> is enough. For example building openbsc with all of its dependencies once with
> and once without ASAN would double our build matrix, yet again. In libosmocore,
> we once run 'make check' with ASAN and then 'make distcheck' without ASAN,
> which completes fairly quickly. We'll have to see what ASAN means for the other
> projects' gerrit build jobs.
>
> For starters, it would be great to fix the ASAN failure seen in
> https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
> Also on my todo-list, but let's see who catches it first :)
>
> ~Neels
>
>

-- 
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 abdulghafar1412 at gmail.com  Wed Oct 26 15:16:37 2016
From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh)
Date: Wed, 26 Oct 2016 16:16:37 +0100
Subject: openbsc - make check error
Message-ID: <CAFeMo5aahtUV=TL9=F3AGSeSM6hyQenDSqBngCiWA451sToumw@mail.gmail.com>

Hi everyone

I was trying Openbsc recently on Ubuntu 16.04.1 and came through these
errors in make check command. Are they harmless? since installation and
make commands were not having any error.

myself at myself34:~/project/openbsc/openbsc$ make check
make  check-recursive
make[1]: Entering directory '/home/myself/project/openbsc/openbsc'
Making check in doc
make[2]: Entering directory '/home/myself/project/openbsc/openbsc/doc'
Making check in examples
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/doc/examples'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/doc/examples'
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/doc'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/doc'
make[2]: Leaving directory '/home/myself/project/openbsc/openbsc/doc'
Making check in include
make[2]: Entering directory '/home/myself/project/openbsc/openbsc/include'
Making check in openbsc
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/include/openbsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/include/openbsc'
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/include'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/include'
make[2]: Leaving directory '/home/myself/project/openbsc/openbsc/include'
Making check in src
make[2]: Entering directory '/home/myself/project/openbsc/openbsc/src'
Making check in libcommon
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libcommon'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/libcommon'
Making check in libmgcp
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libmgcp'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/libmgcp'
Making check in libbsc
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libbsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/src/libbsc'
Making check in libmsc
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libmsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/src/libmsc'
Making check in libtrau
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libtrau'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/libtrau'
Making check in libfilter
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/libfilter'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/libfilter'
Making check in osmo-nitb
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/osmo-nitb'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/osmo-nitb'
Making check in osmo-bsc_mgcp
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc_mgcp'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc_mgcp'
Making check in utils
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/src/utils'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/src/utils'
Making check in ipaccess
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/ipaccess'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/ipaccess'
Making check in gprs
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/src/gprs'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/src/gprs'
Making check in osmo-bsc_nat
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc_nat'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc_nat'
Making check in osmo-bsc
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/src/osmo-bsc'
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/src'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/src'
make[2]: Leaving directory '/home/myself/project/openbsc/openbsc/src'
Making check in tests
make[2]: Entering directory '/home/myself/project/openbsc/openbsc/tests'
Making check in gsm0408
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/gsm0408'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/gsm0408'
Making check in db
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/tests/db'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/db'
Making check in channel
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/channel'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/channel'
Making check in mgcp
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/mgcp'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/mgcp'
Making check in gprs
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/gprs'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/gprs'
Making check in abis
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/abis'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/abis'
Making check in gbproxy
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/gbproxy'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/gbproxy'
Making check in trau
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/trau'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/trau'
Making check in subscr
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/subscr'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/subscr'
Making check in mm_auth
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/mm_auth'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/mm_auth'
Making check in bsc-nat
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/bsc-nat'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/bsc-nat'
Making check in bsc-nat-trie
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/bsc-nat-trie'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/bsc-nat-trie'
Making check in bsc
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/tests/bsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/bsc'
Making check in smpp
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/smpp'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/smpp'
Making check in gtphub
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/gtphub'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/gtphub'
Making check in sgsn
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/sgsn'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/sgsn'
Making check in oap
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/tests/oap'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/oap'
Making check in xid
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/tests/xid'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/xid'
Making check in sndcp_xid
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/sndcp_xid'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/sndcp_xid'
Making check in slhc
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/slhc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests/slhc'
Making check in v42bis
make[3]: Entering directory '/home/myself/project/openbsc/
openbsc/tests/v42bis'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/myself/project/openbsc/
openbsc/tests/v42bis'
make[3]: Entering directory '/home/myself/project/openbsc/openbsc/tests'
make  check-local
make[4]: Entering directory '/home/myself/project/openbsc/openbsc/tests'
:;{ \
               echo '# Signature of the current package.' && \
               echo 'm4_define([AT_PACKAGE_NAME],' && \
               echo '  [openbsc])' && \
               echo 'm4_define([AT_PACKAGE_TARNAME],' && \
               echo '  [openbsc])' && \
               echo 'm4_define([AT_PACKAGE_VERSION],' && \
               echo '  [0.15.0.498-582e4])' && \
               echo 'm4_define([AT_PACKAGE_STRING],' && \
               echo '  [openbsc 0.15.0.498-582e4])' && \
               echo 'm4_define([AT_PACKAGE_BUGREPORT],' && \
               echo '  [openbsc at lists.osmocom.org])'; \
               echo 'm4_define([AT_PACKAGE_URL],' && \
               echo '  [])'; \
             } >'./package.m4'
/bin/bash ../missing --run autom4te --language=autotest -I '.' -o
testsuite.tmp testsuite.at
mv testsuite.tmp testsuite
/bin/bash './testsuite'
## ------------------------------------ ##
## openbsc 0.15.0.498-582e4 test suite. ##
## ------------------------------------ ##

Regression tests.

  1: gsm0408                                         ok
  2: subscr                                          ok
  3: db                                              FAILED (testsuite.at:21
)
  4: channel                                         ok
  5: mgcp                                            ok
  6: mgcp-trans                                      skipped (
testsuite.at:38)
  7: gprs                                            ok
  8: bsc-nat                                         ok
  9: smpp                                            ok
 10: bsc-nat-trie                                    ok
 11: abis                                            ok
 12: bsc                                             ok
 13: gbproxy                                         ok
 14: trau                                            ok
 15: sgsn                                            ok
 16: oap                                             ok
 17: gtphub                                          ok
 18: mm_auth                                         ok
 19: xid                                             ok
 20: sndcp_xid                                       ok
 21: slhc                                            ok
 22: v42bis                                          ok

## ------------- ##
## Test results. ##
## ------------- ##

ERROR: 21 tests were run,
1 failed unexpectedly.
1 test was skipped.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##

Please send `tests/testsuite.log' and all information you think might help:

   To: <openbsc at lists.osmocom.org>
   Subject: [openbsc 0.15.0.498-582e4] testsuite: 3 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `tests/testsuite.dir'.

Makefile:717: recipe for target 'check-local' failed
make[4]: *** [check-local] Error 1
make[4]: Leaving directory '/home/myself/project/openbsc/openbsc/tests'
Makefile:568: recipe for target 'check-am' failed
make[3]: *** [check-am] Error 2
make[3]: Leaving directory '/home/myself/project/openbsc/openbsc/tests'
Makefile:420: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/home/myself/project/openbsc/openbsc/tests'
Makefile:484: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/myself/project/openbsc/openbsc'
Makefile:775: recipe for target 'check' failed
make: *** [check] Error 2
myself at myself34:~/project/openbsc/openbsc$

Thanks
Abdulghafar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161026/5286f32b/attachment.htm>

From nhofmeyr at sysmocom.de  Thu Oct 27 10:44:52 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 27 Oct 2016 12:44:52 +0200
Subject: openbsc - make check error
In-Reply-To: <CAFeMo5aahtUV=TL9=F3AGSeSM6hyQenDSqBngCiWA451sToumw@mail.gmail.com>
References: <CAFeMo5aahtUV=TL9=F3AGSeSM6hyQenDSqBngCiWA451sToumw@mail.gmail.com>
Message-ID: <20161027104452.GB1332@my.box>

Hi,

most of your paste contains standard GNU Make output for entering and leaving
directories. The 'db' test failure is probably due to a missing libdbd-sqlite3
dependency. Install that package and try again.

On Wed, Oct 26, 2016 at 04:16:37PM +0100, Abdulghafar Shabaneh wrote:
[...]
>   3: db                                              FAILED (testsuite.at:21
[...]

-- 
- 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/20161027/81b80bb3/attachment.bin>

From fanx07 at gmail.com  Thu Oct 27 12:42:27 2016
From: fanx07 at gmail.com (Anonim Stefan)
Date: Thu, 27 Oct 2016 15:42:27 +0300
Subject: open-sip-connector error logs
Message-ID: <CAO7wsJvKqkW8TCt45ZSq2EJxQDzWdapZVz1im_vrrfq-rWyBYQ@mail.gmail.com>

Hi,

I am using osmo-sip-connector 1.20161024 with osmocom-nitb 0.15.1.20161024
on debian jessie. I keep getting the below error[1] causing my syslog to
fill up. Also I can see sometimes the sip connector replies with 0.0.0.0
RTP IP address.

Anyone had this issues before ? Any idea what might be causing this?

Regards,
Stefan

[1] Oct 25 11:58:28 openbsc1 osmo-sip-connector[283]: length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettport(0x1064c30): zero length packettport(0x1064c30): zero length
packettpor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161027/64ba7660/attachment.htm>

From holger at freyther.de  Thu Oct 27 13:03:48 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 27 Oct 2016 15:03:48 +0200
Subject: open-sip-connector error logs
In-Reply-To: <CAO7wsJvKqkW8TCt45ZSq2EJxQDzWdapZVz1im_vrrfq-rWyBYQ@mail.gmail.com>
References: <CAO7wsJvKqkW8TCt45ZSq2EJxQDzWdapZVz1im_vrrfq-rWyBYQ@mail.gmail.com>
Message-ID: <7AF29906-DCB5-444E-ADAB-7B6BAE2B44EF@freyther.de>


> On 27 Oct 2016, at 14:42, Anonim Stefan <fanx07 at gmail.com> wrote:
> 
> Hi,
> 
> I am using osmo-sip-connector 1.20161024 with osmocom-nitb 0.15.1.20161024 on debian jessie. I keep getting the below error[1] causing my syslog to fill up. Also I can see sometimes the sip connector replies with 0.0.0.0 RTP IP address.
> 
> Anyone had this issues before ? Any idea what might be causing this?


yes, seen it before. Something internal of oRTP... I have seen it triggered by NAT or wrong configuration.. the oRTP code is very "engineered" so it is not easy to follow why it is doing it or how to stop it. :}

holger

From holger at freyther.de  Sat Oct 29 19:38:13 2016
From: holger at freyther.de (Holger Freyther)
Date: Sat, 29 Oct 2016 21:38:13 +0200
Subject: Profiling data of decoding EPDAN compressed bitmap
In-Reply-To: <B22F7BEF-DD30-4E39-AB6F-136C9B70A324@freyther.de>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
 <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
 <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>
 <DM2PR0801MB665E734822F42A2BBFA86D8972D0@DM2PR0801MB665.namprd08.prod.outlook.com>
 <75AB52FB-ACE2-414E-ACD5-50C363626F51@freyther.de>
 <586CD5D3-1ED6-4D37-891D-782CF846029E@freyther.de>
 <57861620.50909@sysmocom.de>
 <B22F7BEF-DD30-4E39-AB6F-136C9B70A324@freyther.de>
Message-ID: <384CB00B-775A-4BCE-B172-52D78DD210EE@freyther.de>


> On 13 Jul 2016, at 13:51, Holger Freyther <holger at freyther.de> wrote:
> 

Hey!

>> After looking at the code, I don't think reusing table implementation
>> would be easy - the approaches are too different as well as underlying
>> data structures.
> 
> okay. then we will need to use the tree based version and from my point of view we should do it the following way:
> 
> * Remove osmo_t4_decode (and related routines) from libosmocore (last step)
> * Make the tree based decoder ready in terms of the surrounding style
> * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU)
> 
> @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore


thanks to the review and patience of Neels and Harald the tree based t4 decoding is now in osmo-pcu and I have pushed https://gerrit.osmocom.org/1176 for review.

holger