From msuraev at sysmocom.de  Mon Aug  1 11:22:00 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 1 Aug 2016 13:22:00 +0200
Subject: certificate expiration
Message-ID: <65e84191-6e3d-39b4-59f3-fea85f3fe3f2@sysmocom.de>

Hi.

A little heads-up - I've noticed that certificate on gerrit server has
expired:

gerrit.osmocom.org uses an invalid security certificate. The certificate
expired on 08/01/2016 12:24 PM. The current time is 08/01/2016 12:33 PM.

-- 
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  Mon Aug  1 12:29:07 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 1 Aug 2016 14:29:07 +0200
Subject: certificate expiration
In-Reply-To: <65e84191-6e3d-39b4-59f3-fea85f3fe3f2@sysmocom.de>
References: <65e84191-6e3d-39b4-59f3-fea85f3fe3f2@sysmocom.de>
Message-ID: <4FBCD40E-3621-431F-B979-AD86BEE9EEA7@freyther.de>


> On 01 Aug 2016, at 13:22, Max <msuraev at sysmocom.de> wrote:
> 
> Hi.
> 
> A little heads-up - I've noticed that certificate on gerrit server has
> expired:
> 
> gerrit.osmocom.org uses an invalid security certificate. The certificate
> expired on 08/01/2016 12:24 PM. The current time is 08/01/2016 12:33 PM.

letsencrypt.sh should have renewed the certificates but it did not leading to the expiration. I have updated that script and ran by hand and it worked now(tm). Gerrit/Java had some issues trusting the new certificate. I was lazy and imported the fullchain of our then used cert but it looks like keytool only imported the first certificate it saw. It seems to be okay now.

thank you for the report. I will look into adding monitoring to check the expiration is at least 30 days ahead.

	holger

From msuraev at sysmocom.de  Mon Aug  1 14:57:54 2016
From: msuraev at sysmocom.de (Max)
Date: Mon, 1 Aug 2016 16:57:54 +0200
Subject: multiple phy with osmo-trx
Message-ID: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>

Hi!

I've asked about it before but this seems to have been lost in
communication.

The question is basically how to enable multi-TRX support for
osmo-bts-trx using phy/instance infrastructure similar to other bts?

What I've tried so far is documented in
http://projects.osmocom.org/issues/1648 but it did not result in working
setup yet.

In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
missing to make this actually work are greatly appreciated.

-- 
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 tom at tsou.cc  Mon Aug  1 22:39:30 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 1 Aug 2016 15:39:30 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
Message-ID: <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>

Hi Max,

On Mon, Aug 1, 2016 at 7:57 AM, Max <msuraev at sysmocom.de> wrote:
> I've asked about it before but this seems to have been lost in
> communication.

I do not recall this discussion. My apologies.

> The question is basically how to enable multi-TRX support for
> osmo-bts-trx using phy/instance infrastructure similar to other bts?

I use the following configuration.

phy 0
 instance 0
 instance 1
 osmotrx rx-gain 25

bts 0
 band 900
 ipa unit-id 1234 0
 oml remote-ip 127.0.0.1
 settsc
 gsmtap-sapi ccch
 gsmtap-sapi pdtch
 trx 0
  phy 0 instance 0
 trx 1
  phy 0 instance 1

$ osmo-bts-trx -c osmo-bts.cfg -t 2

> In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
> its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
> correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
> missing to make this actually work are greatly appreciated.

You can use "osmo-trx -c 2" or "osmo-trx -m -c 2" to use dual-channels
of the B210 or multi-ARFCN on one channel respectively.

Note that there are ARFCN restrictions for both cases. Due to a shared
local oscillator for both B210 channels, ARFCN separation can be up
about 25 MHz.

With multi-TRX, ARFCN spacing is fixed at 800 kHz or 4 GSM channels.
So if TRX-0 is set to ARFCN 51, TRX-1 _must_ be set to 55. Up to three
ARFCN's is supported for multi-TRX.

  -TT


From tom at tsou.cc  Mon Aug  1 22:57:36 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 1 Aug 2016 15:57:36 -0700
Subject: signal quality measurements in osmo-trx
In-Reply-To: <CABmJbFUi6uCgRgYtoXSmODJFG5RGRW7Kbzst2vqX8-BscJfWaQ@mail.gmail.com>
References: <7657973e-5062-c89e-f311-429b66260de6@sysmocom.de>
 <CABmJbFUi6uCgRgYtoXSmODJFG5RGRW7Kbzst2vqX8-BscJfWaQ@mail.gmail.com>
Message-ID: <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>

On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial
> to pass through.

Yes. I don't know where the TOA value ends up in osmo-bts, but the
value is definitely carried per-burst on the socket interface.

> For C/I we need a comment from Thomas. Currently we don't have it on the
> osmo-trx interface and I'm not even sure we calculate it.

We don't have C/I directly. We do have a running average 'noise' level
(calculated channel power on non-active uplink slots) and the RSSI
value. The channel noise is queried with the NOISELEV command. RSSI is
carried per-burst on the socket message. C/I can be calculated from
those two values.

Do we need a periodically averaged C/I value or an update every burst?

  -TT


From laforge at gnumonks.org  Tue Aug  2 06:22:44 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 2 Aug 2016 08:22:44 +0200
Subject: signal quality measurements in osmo-trx
In-Reply-To: <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>
References: <7657973e-5062-c89e-f311-429b66260de6@sysmocom.de>
 <CABmJbFUi6uCgRgYtoXSmODJFG5RGRW7Kbzst2vqX8-BscJfWaQ@mail.gmail.com>
 <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>
Message-ID: <20160802062244.GD4087@nataraja>

Hi Tom,

On Mon, Aug 01, 2016 at 03:57:36PM -0700, Tom Tsou wrote:
> On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris
> <alexander.chemeris at gmail.com> wrote:
> > Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial
> > to pass through.
> 
> Yes. I don't know where the TOA value ends up in osmo-bts, but the
> value is definitely carried per-burst on the socket interface.
> 
> > For C/I we need a comment from Thomas. Currently we don't have it on the
> > osmo-trx interface and I'm not even sure we calculate it.
> 
> We don't have C/I directly. We do have a running average 'noise' level
> (calculated channel power on non-active uplink slots) and the RSSI
> value. The channel noise is queried with the NOISELEV command. RSSI is
> carried per-burst on the socket message. C/I can be calculated from
> those two values.

This long-time average noise level would make sens on a per-timeslot
basis, or evne on a per-lchan basis once osmo-bts started to send uplink
interference indications to the BSC (which currently it doesn't, on any
BTS model).

> Do we need a periodically averaged C/I value or an update every burst?

The background of this current question is GPRS, where an average over
multiple blocks inside a timeslot is not useful, as the resources are
scheduled fully dynamic.

So to me, averaging over more than the four bursts of one block seems to
make sense only in the context of circuit-switched channels, where the
dedicated channel of a single MS is averaged.  But for GPRS, every block
might be a different MS, and the interference into the specific
dynamically allocated uplink blocks within the TBF might be completely
different than for other blocks scheduled to other MS.

I'm assuming that one of the most common interference patterns in
GSM/GPRS is from other networks/cells, which most commonly use frequency
hopping, and thus the uplink interference from one block to another (on
a non-hopping OsmoBTS) could be significantly different.

Literature describes GPRS link adation algorithms based on either CIR
or BLER, so we should have both available in the PCU to play with
different algorithms.

For EGPRS, the values we need to report into the PCU (specifically the
link adaption) are MEAN_BEP and CV_BEP.

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


From msuraev at sysmocom.de  Wed Aug  3 09:51:28 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 3 Aug 2016 11:51:28 +0200
Subject: control interface variable naming
Message-ID: <c6e0231d-bb2a-8dac-112f-ffc4c39b99aa@sysmocom.de>

Hi.

It's nitpicking time :)

I've noticed that variables exposed over control interface (see
osmobsc-usermanual.pdf for example) are named differently - some use _
(e. g. bts_connection_status) others use - (e. g. short-name). Which
variant is preferred if any?

-- 
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  Thu Aug  4 11:50:39 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 4 Aug 2016 17:50:39 +0600
Subject: OsmoBTS -> libosmogsm code migration
Message-ID: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>

Dear all,

We recently discussed with Harald, that there is a lot of code related to
GSM L1 should be migrated from OsmoBTS to libosmogsm. The reason is that
it would be better to have one shared implementation of the convolutional
codes, mapping, interleaving, etc., because then in near future it can be
used not only from OsmoBTS, but also from OsmocomBB and even from foreign
projects, such as GR-GSM.

I just started to work on this direction, and found that there is already
some code, related to the conventional codes, in libosmogsm. But unlike
OsmoBTS, where all the tables can be found within the single file named
'gsm0503_conv.c', these tables appears in separate files during building
process. So, I have several questions:

1) Which approach is better to use? To store everything in a single file
or to use auto generation (utils/conv_gen.py)?
2) What about the copyright? I have not seen any license/author info at
the top pf these files. Who is the author?

Also, there is the 'gsm0503_coding.c' file, which uses the following
external dependences:

 * The DL1C logging category, which isn't defined in libosmocore;
 * The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h'
     as well.

So, there is regarding questions:

3) Which logging category it would be better to use after migration?
4) What to do with the 'osmo-bts/gsm_data.h'?
5) I don't think, that it's a good way to require something from the
OpenBSC sources during OsmoBTS build... How can we change it?

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

From msuraev at sysmocom.de  Thu Aug  4 12:54:17 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 4 Aug 2016 14:54:17 +0200
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>
References: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>
Message-ID: <05a10629-2602-5f73-4e42-85ac47073d73@sysmocom.de>

Hi.

I think I can answer some of the questions. See comments below.


On 08/04/2016 01:50 PM, Vadim Yanitskiy wrote:
>
>
> 1) Which approach is better to use? To store everything in a single file
> or to use auto generation (utils/conv_gen.py)?

I think extending utils/conv_gen.py is the way to go because it will
allow us to have concise description of the convolutional codes in one
place and as close to the description in standards as possible.

> 2) What about the copyright? I have not seen any license/author info at
> the top pf these files. Who is the author?

Could you specify which files exactly are you referring to? Also you can
use 'git blame' to clarify authorship.

>
> Also, there is the 'gsm0503_coding.c' file, which uses the following
> external dependences:
>
>  * The DL1C logging category, which isn't defined in libosmocore;

I don't think library functions should do any sort of logging by itself
(unless it's a logging functions of course :)
Instead they should return clearly distinguishable values and let caller
do the logging as they see fit.

-- 
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 Aug  4 13:23:11 2016
From: msuraev at sysmocom.de (msuraev at sysmocom.de)
Date: Thu,  4 Aug 2016 15:23:11 +0200
Subject: [PATCH] Add Control Interface port numbers
Message-ID: <20160804132311.2173-1-msuraev@sysmocom.de>

From: Max <msuraev at sysmocom.de>

Related: OS#1646
---
 common/chapters/port_numbers.adoc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/chapters/port_numbers.adoc b/common/chapters/port_numbers.adoc
index 695cc6c..0430b13 100644
--- a/common/chapters/port_numbers.adoc
+++ b/common/chapters/port_numbers.adoc
@@ -22,6 +22,8 @@ which protocol / interface.
 |TCP|4246|telnet (VTY)|osmo-gbproxy
 |TCP|4249|Control Interface|osmo-nitb, osmo-bsc
 |TCP|4250|Control Interface|osmo-bsc_nat
+|TCP|4251|Control Interface|osmo-sgsn
+|TCP|4252|Control Interface|openggsn
 |TCP|5000|A/IP|osmo-bsc, osmo-bsc_nat
 |UDP|2427|GSMTAP|osmo-pcu, osmo-bts
 |UDP|23000|GPRS-NS over IP default port|osmo-pcu, osmo-sgsn, osmo-gbproxy
-- 
2.9.2



From axilirator at gmail.com  Thu Aug  4 13:51:40 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 4 Aug 2016 19:51:40 +0600
Subject: OsmoBTS -> libosmogsm code migration
Message-ID: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>

Hi Max,

Thanks for your reply!

> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.

Ok, I will keep your opinion in my mind.

> Could you specify which files exactly are you referring to? Also you can
> use 'git blame' to clarify authorship.

No problem, they are:

 - gsm0503_conv.c
 - gsm0503_interleaving.c
 - gsm0503_mapping.c
 - gsm0503_parity.c
 - gsm0503_tables.c

Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
Thank you for this hint, this command is very usable! :)

> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.

I am agree with you. It's time to use return codes.

Have a nice day!


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

From msuraev at sysmocom.de  Thu Aug  4 16:18:32 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 4 Aug 2016 18:18:32 +0200
Subject: signal quality measurements in osmo-trx
In-Reply-To: <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>
References: <7657973e-5062-c89e-f311-429b66260de6@sysmocom.de>
 <CABmJbFUi6uCgRgYtoXSmODJFG5RGRW7Kbzst2vqX8-BscJfWaQ@mail.gmail.com>
 <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>
Message-ID: <0be46667-738f-d832-e93c-edd21e335017@sysmocom.de>

Please have a look at gerrit #623 - am I computing BER properly? I've
tried to follow what's done for meas. ind. Also, how would you recommend
to compute/estimate C/I? In the current patch version I'm just using 0.

On 08/02/2016 12:57 AM, Tom Tsou wrote:
> On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris
> <alexander.chemeris at gmail.com> wrote:
>> Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial
>> to pass through.
> Yes. I don't know where the TOA value ends up in osmo-bts, but the
> value is definitely carried per-burst on the socket interface.
>
>> For C/I we need a comment from Thomas. Currently we don't have it on the
>> osmo-trx interface and I'm not even sure we calculate it.
> We don't have C/I directly. We do have a running average 'noise' level
> (calculated channel power on non-active uplink slots) and the RSSI
> value. The channel noise is queried with the NOISELEV command. RSSI is
> carried per-burst on the socket message. C/I can be calculated from
> those two values.
>
> Do we need a periodically averaged C/I value or an update every burst?
>
>   -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 alexander.chemeris at gmail.com  Thu Aug  4 17:32:15 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 4 Aug 2016 20:32:15 +0300
Subject: signal quality measurements in osmo-trx
In-Reply-To: <0be46667-738f-d832-e93c-edd21e335017@sysmocom.de>
References: <7657973e-5062-c89e-f311-429b66260de6@sysmocom.de>
 <CABmJbFUi6uCgRgYtoXSmODJFG5RGRW7Kbzst2vqX8-BscJfWaQ@mail.gmail.com>
 <CAATyM+bxLYikaPse5hY3oD=yrC0Pn72L48mb-G-Jb=XNc-=78Q@mail.gmail.com>
 <0be46667-738f-d832-e93c-edd21e335017@sysmocom.de>
Message-ID: <CABmJbFWSpz6SyZMsyM5t01G+Ki2gF4hDAAZQ_R1sFOuKsCWktg@mail.gmail.com>

Calculation looks correct. Have you tested it? IIRC I added tests for BER
calculations which you could extend.

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

On Aug 4, 2016 19:18, "Max" <msuraev at sysmocom.de> wrote:

> Please have a look at gerrit #623 - am I computing BER properly? I've
> tried to follow what's done for meas. ind. Also, how would you recommend
> to compute/estimate C/I? In the current patch version I'm just using 0.
>
> On 08/02/2016 12:57 AM, Tom Tsou wrote:
> > On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris
> > <alexander.chemeris at gmail.com> wrote:
> >> Burst timing is also passed from osmo-trx to osmo-bts, so should be
> trivial
> >> to pass through.
> > Yes. I don't know where the TOA value ends up in osmo-bts, but the
> > value is definitely carried per-burst on the socket interface.
> >
> >> For C/I we need a comment from Thomas. Currently we don't have it on the
> >> osmo-trx interface and I'm not even sure we calculate it.
> > We don't have C/I directly. We do have a running average 'noise' level
> > (calculated channel power on non-active uplink slots) and the RSSI
> > value. The channel noise is queried with the NOISELEV command. RSSI is
> > carried per-burst on the socket message. C/I can be calculated from
> > those two values.
> >
> > Do we need a periodically averaged C/I value or an update every burst?
> >
> >   -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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160804/14e96fda/attachment.htm>

From ptrkrysik at gmail.com  Fri Aug  5 08:23:31 2016
From: ptrkrysik at gmail.com (Piotr Krysik)
Date: Fri, 5 Aug 2016 10:23:31 +0200
Subject: Development of rtl-sdr driver
Message-ID: <1802ccb1-85c7-4a10-7544-9dc878ccb172@gmail.com>

Hi everyone,

The osmocom's version of rtl-sdr driver seems to be the main one.
Osmocom's repository is used by distributions to build rtl-sdr packages
and it is source of the code for compilation with use of GNU Radio's
Pybombs.

Is there someone in the Osmocom who is maintaining it? There were some
important developments regarding this driver and it would be great to
add this patches in the Osmocom's repo.

For example one that interests me is turning off dithering so multiple
dongles sharing the same clock generate the same LO frequency.Currently
there is always little frequency offset that makes coherent of the
receivers operation much harder.

Such changes of course have to be done carefully so nothing gets broken
in the process. In case of turning off dithering it results with worse
tuning granularity, so for example turning it off can be made optional.

-- 
Best Regards,
Piotr Krysik


From axilirator at gmail.com  Fri Aug  5 20:46:06 2016
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sat, 6 Aug 2016 02:46:06 +0600
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>
References: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>
Message-ID: <CAPEnp=Ym+RvE_LSdDf1V97NvSgGOTQZaoE1hwZ36x67WWhW9TA@mail.gmail.com>

Hi all!

I would like to inform, that this task is almost finished! Just tested
my changes, and build was successful without any warnings. But I still
have a couple of unresolved issues:

I have some problems with understanding how to add a new item into the
convolutional codes generator (utils/conv_gen.py), so temporary I just
used a single file from OsmoBTS (gsm0503_conv.c) to check, if all the
rest forks fine. If someone (Max?) can help me to move missed tables
(mostly EGPRS specific, see 73cb583e5147a267a370c576e8ac77507de6d0d7),
I will be grateful, and the task will be completely finished soon.

Also, there are several external dependences from libosmocodec, such as:

 - gsm620_unvoiced_bitorder
 - gsm620_voiced_bitorder
 - gsm660_bitorder
 - gsm610_bitorder

They are some uint16_t arrays, related to GSM HR, FR and EFR. It's sadly,
that they cannot be included using exactly corresponding header files.
I think there are three possible ways to solve this problem:

 1. Link gsm620.c, gsm660.c and gsm610.c to libosmogsm sources.
     (I am not sure, that it is a good way...)
 2. Copy required arrays to libosmogsm (also unlikely).
 3. Add libosmocodec.la as dependence (I suggest exactly this solution):
     - libgsmint_la_LIBADD = ../libosmocore.la
     + libgsmint_la_LIBADD = ../libosmocore.la ../codec/libosmocodec.la

All other problems was solved.


With best regards,
Vadim Yanitskiy.

2016-08-04 19:51 GMT+06:00 Vadim Yanitskiy <axilirator at gmail.com>:

> Hi Max,
>
> Thanks for your reply!
>
> > I think extending utils/conv_gen.py is the way to go because it will
> > allow us to have concise description of the convolutional codes in one
> > place and as close to the description in standards as possible.
>
> Ok, I will keep your opinion in my mind.
>
> > Could you specify which files exactly are you referring to? Also you can
> > use 'git blame' to clarify authorship.
>
> No problem, they are:
>
>  - gsm0503_conv.c
>  - gsm0503_interleaving.c
>  - gsm0503_mapping.c
>  - gsm0503_parity.c
>  - gsm0503_tables.c
>
> Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
> Thank you for this hint, this command is very usable! :)
>
> > I don't think library functions should do any sort of logging by itself
> > (unless it's a logging functions of course :)
> > Instead they should return clearly distinguishable values and let caller
> > do the logging as they see fit.
>
> I am agree with you. It's time to use return codes.
>
> Have a nice day!
>
>
> With best regards,
> Vadim Yanitskiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160806/cd1e2f61/attachment.htm>

From tom at tsou.cc  Fri Aug  5 21:29:44 2016
From: tom at tsou.cc (Tom Tsou)
Date: Fri, 5 Aug 2016 14:29:44 -0700
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=Ym+RvE_LSdDf1V97NvSgGOTQZaoE1hwZ36x67WWhW9TA@mail.gmail.com>
References: <CAPEnp=YzvB2G2ENX66TZA7OhHvKbzAcAeFnZMXMjXhKFx-82ew@mail.gmail.com>
 <CAPEnp=Ym+RvE_LSdDf1V97NvSgGOTQZaoE1hwZ36x67WWhW9TA@mail.gmail.com>
Message-ID: <CAATyM+a6n2xBT9MVtUQG7DcrQGi=7k9TbrN8cqeu56Nz9ygQkw@mail.gmail.com>

Hi Vadim,

On Fri, Aug 5, 2016 at 1:46 PM, Vadim Yanitskiy <axilirator at gmail.com> wrote:
> I would like to inform, that this task is almost finished! Just tested
> my changes, and build was successful without any warnings. But I still
> have a couple of unresolved issues:

This is great.

> I have some problems with understanding how to add a new item into the
> convolutional codes generator (utils/conv_gen.py), so temporary I just
> used a single file from OsmoBTS (gsm0503_conv.c) to check, if all the
> rest forks fine. If someone (Max?) can help me to move missed tables
> (mostly EGPRS specific, see 73cb583e5147a267a370c576e8ac77507de6d0d7),
> I will be grateful, and the task will be completely finished soon.

With regards to convolutional coding, the main difference between GPRS
and EGPRS will be the use of tail-biting recursive codes.

Max, can the utility generate recursive state tables?

  -TT


From abdulghafar1412 at gmail.com  Thu Aug  4 12:07:54 2016
From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh)
Date: Thu, 4 Aug 2016 13:07:54 +0100
Subject: Error in making OsmoNITB on Linux
Message-ID: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>

Hello,

I am trying to install Openbsc on the raspberry pi.  I get this error (in
the attachment ) when I use make. After ./configure) .

Is there a problem in ipaccess.nano? Recently. If it is optional . Is it
safe to remove it entirely since I am using USRP ?

Thanks
Abdulghafar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160804/d7f4ca5b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6 error.PNG
Type: image/png
Size: 36813 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160804/d7f4ca5b/attachment.png>

From laforge at gnumonks.org  Mon Aug  8 08:48:57 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 8 Aug 2016 10:48:57 +0200
Subject: Development of rtl-sdr driver
In-Reply-To: <1802ccb1-85c7-4a10-7544-9dc878ccb172@gmail.com>
References: <1802ccb1-85c7-4a10-7544-9dc878ccb172@gmail.com>
Message-ID: <20160808084857.GD6237@nataraja>

Hi Piotr,

On Fri, Aug 05, 2016 at 10:23:31AM +0200, Piotr Krysik wrote:
> The osmocom's version of rtl-sdr driver seems to be the main one.

Indeed, rtl-sdr was created by some people (primarily Steve) within
Osmocom.  You can see the history in the git repository.

> Is there someone in the Osmocom who is maintaining it? There were some
> important developments regarding this driver and it would be great to
> add this patches in the Osmocom's repo.

https://osmocom.org/projects/sdr/wiki/Rtl-sdr#Mailing-List is the place
for patches and related discsusions.

Regards,
	Harald

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


From laforge at gnumonks.org  Mon Aug  8 08:46:23 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 8 Aug 2016 10:46:23 +0200
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <05a10629-2602-5f73-4e42-85ac47073d73@sysmocom.de>
References: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>
 <05a10629-2602-5f73-4e42-85ac47073d73@sysmocom.de>
Message-ID: <20160808084623.GC6237@nataraja>

Hi Max and others,

On Thu, Aug 04, 2016 at 02:54:17PM +0200, Max wrote:

> > 1) Which approach is better to use? To store everything in a single file
> > or to use auto generation (utils/conv_gen.py)?
> 
> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.

agreed.

> >  * The DL1C logging category, which isn't defined in libosmocore;
> 
> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.

I tend to agree in the case of the convolutional coding - but we do have
plenty of library code that makes use of logging.  See the LAPD / LAPDm
code, for example.

There's two options for this, either:

a) introduce a DL___ logging category which "lives" entirely inside the
   library (like LAPD), or
b) have the application pass in the log sub-system value to be used by
   the library code (used e.g. in FSM code)

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


From holger at freyther.de  Mon Aug  8 11:10:06 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 8 Aug 2016 13:10:06 +0200
Subject: CI infrastructure changes
Message-ID: <4C40E6A0-B6D5-4BB1-B7A3-8753AC3060CC@freyther.de>

Hi,

the CI infrastructure exists because I found it import to have all Osmocom software compile and I set-up the Jenkins on my personal infrastructure. Since the adoption of gerrit having a stable build infrastructure is crucial though and my set-up was too flawed.

In the past the VirtualBox running the Linux node got stuck and needed manual intervention. As it was  running on my private system I was the only one capable of doing that. Sysmocom has offered to rent a dedicated build system and I have used some of my freelancing time to do the migration.

* The Jenkins UI/Server jail has been migrated to the system that runs most of the other Osmocom infrastructure. DNS should be updated soon and then TLS will be enabled for the login.

* OsmocomBuild1 is a Debian8.0/amd64 build slave with plenty of RAM and running on a SSD. All Linux builds should have been migrated away from the Ubuntu-1504-64 system to it.

* rtl-sdr has some funny issue with make uninstall and Doxygen. If someone wants to fix it please go ahead, otherwise I will probably disable doxygen for this build.

* I tried to have OpenBSC/OpenBSC-gerrit run in docker[1] so we can run all configurations at the same time but Jenkins is stepping on itself (and removing files from one label and impacting the other).  At least we seem to have a benefit if two people upload changes at the same time.


kind regards
	holger



[1] I would prefer something without a server (as aborting a build doesn't abort the container) but still convenient enough to just create a new network namespace and remove it on exit

[2] We are only executing the four configurations in parallel as the "build concurrently" option is stepping on each other (files vanish, etc).

From nhofmeyr at sysmocom.de  Mon Aug  8 14:49:29 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 8 Aug 2016 16:49:29 +0200
Subject: [OSMO-TRX PATCH] remove INSTALL file to have a clean git status
In-Reply-To: <CABmJbFU7HRnj5-Wk_N_BCs1i1g7GGcEXCuyG0jgY_hwyTu5z2g@mail.gmail.com>
References: <1469724033-27105-1-git-send-email-nhofmeyr@sysmocom.de>
 <CABmJbFU7HRnj5-Wk_N_BCs1i1g7GGcEXCuyG0jgY_hwyTu5z2g@mail.gmail.com>
Message-ID: <20160808144929.GB4437@dub7>

On Fri, Jul 29, 2016 at 08:19:26PM -0400, Alexander Chemeris wrote:
> Really good idea. That has been annoying thing.

Yes -- let me flag it more prominently as an osmo-trx patch, maybe we can have
this merged one day :)

Merging patches to osmo-trx is currently TT's privilege & responsibility,
right? Ah, I also see some commits by Alexander... should I push this myself,
then? (I wonder whether I have push access)

~Neels

> On Jul 28, 2016 12:40, "Neels Hofmeyr" <nhofmeyr at sysmocom.de> wrote:
> 
> > From: Neels Hofmeyr <neels at hofmeyr.de>
> >
> > The INSTALL file is being overwritten by autoreconf, but it is committed
> > as empty file. As a result, the INSTALL file always shows as modified.
> > Instead, remove INSTALL from git and ignore it.
> > ---
> >  .gitignore | 1 +
> >  INSTALL    | 0
> >  2 files changed, 1 insertion(+)
> >  delete mode 100644 INSTALL
> >
> > diff --git a/.gitignore b/.gitignore
> > index e15c19b..d1a0b33 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -39,6 +39,7 @@ libtool
> >  ltmain.sh
> >  missing
> >  stamp-h1
> > +INSTALL
> >
> >  # vim
> >  *.sw?
> > diff --git a/INSTALL b/INSTALL
> > deleted file mode 100644
> > index e69de29..0000000
> > --
> > 2.1.4
> >
> >

-- 
- 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/20160808/e12e8ed0/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Aug  8 17:06:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 8 Aug 2016 19:06:01 +0200
Subject: OsmoBTS -> libosmogsm code migration
In-Reply-To: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>
References: <CAPEnp=bB0wJF-NJ2XXgLgqzWvdQZWBQp8YDBWGSzM8sm_SH1Pw@mail.gmail.com>
Message-ID: <20160808170601.GC4437@dub7>

On Thu, Aug 04, 2016 at 05:50:39PM +0600, Vadim Yanitskiy wrote:
>  * The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h'
>      as well.
> 
> So, there is regarding questions:
> 
> 3) Which logging category it would be better to use after migration?
> 4) What to do with the 'osmo-bts/gsm_data.h'?
> 5) I don't think, that it's a good way to require something from the
> OpenBSC sources during OsmoBTS build... How can we change it?

I've also faced the problem twice recently that I effectively can't log from
gsm_data_shared.c, since the logging constants (e.g. DRSL) are defined
separately for openbsc and osmo-bts (can't include both headers...).

The first time I solved it by returning an error code and code-dup'ing the
error logging in osmo-bts and openbsc (see lchan_lookup() in
openbsc/src/libbsc/abis_rsl.c and osmo-bts/src/common/rsl.c).

The other time I placed a compile time #warning where I'd have preferred to
post an error log (not committed yet).

The one advantage of gsm_data_shared.c is that I feel that I can modify that
API without breaking any libosmocore ABI. We can pretty freely drop stuff in
there and re-use across openbsc and osmo-bts that isn't used anywhere else.

But I find these solutions rather unsatisfactory / ugly and would +1 for
solving the gsm_data_shared.c evil-twin situation. If some of the stuff isn't
worthy of moving to libosmocore, we'd need another tiny osmo-lib?

~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/20160808/6e52ff71/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Aug  8 17:46:57 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 8 Aug 2016 19:46:57 +0200
Subject: Error in making OsmoNITB on Linux
In-Reply-To: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>
References: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>
Message-ID: <20160808174657.GA25602@dub7>

Hi Abdulghafar,

the bts_ipaccess_nanobts.c code cannot be removed and this should anyway not be
the cause of your problem.

The way the openbsc build works for me is:

using

	git clone git://git.osmocom.org/$PROJECT

check out all of

	libosmocore
	libosmo-abis
	libosmo-netif
	libosmo-sccp
	openggsn
	libsmpp34
	openbsc

then in each (and in this order)

	cd $PROJECT
	autoreconf -fi
	./configure
	make install

For openbsc, you need to
	
	cd openbsc/openbsc
	autoreconf -fi
	./configure --enable-smpp  (and maybe: --enable-osmo-bsc --enable-nat )
	make install


If this doesn't work for you, ask again here, and:

- provide *all* your build steps and *all* of its terminal output

- if you do so, please do *not ever* send bitmap images of screenshots, but
  post the *plain text* commands and output as copy-pasted from your terminal.

- also tell us exactly how you obtained the source code (i.e. which git
  revision you are using).

I hope this helps,

~Neels


On Thu, Aug 04, 2016 at 01:07:54PM +0100, Abdulghafar Shabaneh wrote:
> Hello,
> 
> I am trying to install Openbsc on the raspberry pi.  I get this error (in
> the attachment ) when I use make. After ./configure) .
> 
> Is there a problem in ipaccess.nano? Recently. If it is optional . Is it
> safe to remove it entirely since I am using USRP ?
> 
> Thanks
> Abdulghafar


-- 
- 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/20160808/745eb390/attachment.bin>

From alexander.chemeris at gmail.com  Mon Aug  8 18:18:10 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 8 Aug 2016 21:18:10 +0300
Subject: [OSMO-TRX PATCH] remove INSTALL file to have a clean git status
In-Reply-To: <20160808144929.GB4437@dub7>
References: <1469724033-27105-1-git-send-email-nhofmeyr@sysmocom.de>
 <CABmJbFU7HRnj5-Wk_N_BCs1i1g7GGcEXCuyG0jgY_hwyTu5z2g@mail.gmail.com>
 <20160808144929.GB4437@dub7>
Message-ID: <CABmJbFXjPo2YgxgN41H=NWEtMQLAdCSc8=x4=iL7UJMqu+tJRQ@mail.gmail.com>

I suggest the following procedure which worked well for me:
1. Commit your patches to a branch on top of master.
2. Ping Thomas here or privately about your branch.
3. Repeat (2) until merged.

I don't push to master myself, because Thomas is maintaining it and I don't
want to abuse this.

Please excuse typos. Written with a touchscreen keyboard.

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

On Aug 8, 2016 5:49 PM, "Neels Hofmeyr" <nhofmeyr at sysmocom.de> wrote:

> On Fri, Jul 29, 2016 at 08:19:26PM -0400, Alexander Chemeris wrote:
> > Really good idea. That has been annoying thing.
>
> Yes -- let me flag it more prominently as an osmo-trx patch, maybe we can
> have
> this merged one day :)
>
> Merging patches to osmo-trx is currently TT's privilege & responsibility,
> right? Ah, I also see some commits by Alexander... should I push this
> myself,
> then? (I wonder whether I have push access)
>
> ~Neels
>
> > On Jul 28, 2016 12:40, "Neels Hofmeyr" <nhofmeyr at sysmocom.de> wrote:
> >
> > > From: Neels Hofmeyr <neels at hofmeyr.de>
> > >
> > > The INSTALL file is being overwritten by autoreconf, but it is
> committed
> > > as empty file. As a result, the INSTALL file always shows as modified.
> > > Instead, remove INSTALL from git and ignore it.
> > > ---
> > >  .gitignore | 1 +
> > >  INSTALL    | 0
> > >  2 files changed, 1 insertion(+)
> > >  delete mode 100644 INSTALL
> > >
> > > diff --git a/.gitignore b/.gitignore
> > > index e15c19b..d1a0b33 100644
> > > --- a/.gitignore
> > > +++ b/.gitignore
> > > @@ -39,6 +39,7 @@ libtool
> > >  ltmain.sh
> > >  missing
> > >  stamp-h1
> > > +INSTALL
> > >
> > >  # vim
> > >  *.sw?
> > > diff --git a/INSTALL b/INSTALL
> > > deleted file mode 100644
> > > index e69de29..0000000
> > > --
> > > 2.1.4
> > >
> > >
>
> --
> - 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/20160808/807f14c6/attachment.htm>

From tom at tsou.cc  Mon Aug  8 18:57:33 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 8 Aug 2016 11:57:33 -0700
Subject: [OSMO-TRX PATCH] remove INSTALL file to have a clean git status
In-Reply-To: <20160808144929.GB4437@dub7>
References: <1469724033-27105-1-git-send-email-nhofmeyr@sysmocom.de>
 <CABmJbFU7HRnj5-Wk_N_BCs1i1g7GGcEXCuyG0jgY_hwyTu5z2g@mail.gmail.com>
 <20160808144929.GB4437@dub7>
Message-ID: <CAATyM+aFN-U2jv=8xUVoW_DChdWxXBs-vtuc+Wdh50=5vjje7g@mail.gmail.com>

On Mon, Aug 8, 2016 at 7:49 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> On Fri, Jul 29, 2016 at 08:19:26PM -0400, Alexander Chemeris wrote:
>> Really good idea. That has been annoying thing.
>
> Yes -- let me flag it more prominently as an osmo-trx patch, maybe we can have
> this merged one day :)

Merged. And yes, please noticeably flag as osmo-trx.

  -TT


From msuraev at sysmocom.de  Tue Aug  9 10:44:11 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 9 Aug 2016 12:44:11 +0200
Subject: CI infrastructure changes
In-Reply-To: <4C40E6A0-B6D5-4BB1-B7A3-8753AC3060CC@freyther.de>
References: <4C40E6A0-B6D5-4BB1-B7A3-8753AC3060CC@freyther.de>
Message-ID: <5b0483b6-bb7b-0181-b70e-d6f638eb9490@sysmocom.de>

This makes me wonder if any of

https://travis-ci.org/

https://app.wercker.com/sessions/new

https://app.shippable.com/pricing.html

are worth looking into. Have not tried in practice so don't know how
much pain it's to use for project outside of github or how it integrates
with gerrit. Maybe someone in the community had some experience with
CI-as-a-service?


On 08/08/2016 01:10 PM, Holger Freyther wrote:
> Hi,
>
> the CI infrastructure exists because I found it import to have all Osmocom software compile and I set-up the Jenkins on my personal infrastructure. Since the adoption of gerrit having a stable build infrastructure is crucial though and my set-up was too flawed.
>
> In the past the VirtualBox running the Linux node got stuck and needed manual intervention. As it was  running on my private system I was the only one capable of doing that. Sysmocom has offered to rent a dedicated build system and I have used some of my freelancing time to do the migration.
>
> * The Jenkins UI/Server jail has been migrated to the system that runs most of the other Osmocom infrastructure. DNS should be updated soon and then TLS will be enabled for the login.
>
> * OsmocomBuild1 is a Debian8.0/amd64 build slave with plenty of RAM and running on a SSD. All Linux builds should have been migrated away from the Ubuntu-1504-64 system to it.
>
> * rtl-sdr has some funny issue with make uninstall and Doxygen. If someone wants to fix it please go ahead, otherwise I will probably disable doxygen for this build.
>
> * I tried to have OpenBSC/OpenBSC-gerrit run in docker[1] so we can run all configurations at the same time but Jenkins is stepping on itself (and removing files from one label and impacting the other).  At least we seem to have a benefit if two people upload changes at the same time.
>
>
> kind regards
> 	holger
>
>
>
> [1] I would prefer something without a server (as aborting a build doesn't abort the container) but still convenient enough to just create a new network namespace and remove it on exit
>
> [2] We are only executing the four configurations in parallel as the "build concurrently" option is stepping on each other (files vanish, etc).

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From nhofmeyr at sysmocom.de  Tue Aug  9 19:40:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 9 Aug 2016 21:40:01 +0200
Subject: osmo-trx: only one TCH/H lchan
Message-ID: <20160809194001.GC3660@ass40.sysmocom.de>

I'd just like to draw attention to an issue that I've just reported:
osmo-bts-trx: fails to assign second lchan on TCH/H TS
http://osmocom.org/issues/1795

Comments and supplementary facts are welcome!

~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/20160809/0d4dca27/attachment.bin>

From msuraev at sysmocom.de  Wed Aug 10 13:42:49 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 10 Aug 2016 15:42:49 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
Message-ID: <aab35bd4-863b-adce-5ac1-d3594d62b77b@sysmocom.de>

Hi.

Unfortunately I'm unable to make it work yet:

sudo chrt 20 ./Transceiver52M/osmo-trx -m -c 2 -g

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

opening configuration table from path :memory:
Config Settings
   Log Level............... NOTICE
   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

-- 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
-- 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 3036182272 15:41:43.1 UHDDevice.cpp:546:set_master_clk: Failed to
set master clock rate
ALERT 3036182272 15:41:43.1 UHDDevice.cpp:546:set_master_clk: Failed to
set master clock rate
ALERT 3036182272 15:41:43.1 UHDDevice.cpp:547:set_master_clk: Requested
clock rate 3.2e+06
ALERT 3036182272 15:41:43.1 UHDDevice.cpp:547:set_master_clk: Requested
clock rate 3.2e+06
ALERT 3036182272 15:41:43.1 UHDDevice.cpp:548:set_master_clk: Actual
clock rate 5e+06
ALERT 3036182272 15:41:43.1 UHDDevice.cpp:548:set_master_clk: Actual
clock rate 5e+06
ALERT 3036182272 15:41:43.1 osmo-trx.cpp:530:main: Failed to create
radio device

ALERT 3036182272 15:41:43.1 osmo-trx.cpp:530:main: Failed to create
radio device
Shutting down transceiver...


On 08/02/2016 12:39 AM, Tom Tsou wrote:
> Hi Max,
>
> On Mon, Aug 1, 2016 at 7:57 AM, Max <msuraev at sysmocom.de> wrote:
>> I've asked about it before but this seems to have been lost in
>> communication.
> I do not recall this discussion. My apologies.
>
>> The question is basically how to enable multi-TRX support for
>> osmo-bts-trx using phy/instance infrastructure similar to other bts?
> I use the following configuration.
>
> phy 0
>  instance 0
>  instance 1
>  osmotrx rx-gain 25
>
> bts 0
>  band 900
>  ipa unit-id 1234 0
>  oml remote-ip 127.0.0.1
>  settsc
>  gsmtap-sapi ccch
>  gsmtap-sapi pdtch
>  trx 0
>   phy 0 instance 0
>  trx 1
>   phy 0 instance 1
>
> $ osmo-bts-trx -c osmo-bts.cfg -t 2
>
>> In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
>> its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
>> correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
>> missing to make this actually work are greatly appreciated.
> You can use "osmo-trx -c 2" or "osmo-trx -m -c 2" to use dual-channels
> of the B210 or multi-ARFCN on one channel respectively.
>
> Note that there are ARFCN restrictions for both cases. Due to a shared
> local oscillator for both B210 channels, ARFCN separation can be up
> about 25 MHz.
>
> With multi-TRX, ARFCN spacing is fixed at 800 kHz or 4 GSM channels.
> So if TRX-0 is set to ARFCN 51, TRX-1 _must_ be set to 55. Up to three
> ARFCN's is supported for multi-TRX.
>
>   -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 msuraev at sysmocom.de  Wed Aug 10 14:17:09 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 10 Aug 2016 16:17:09 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
Message-ID: <fb6a2461-2567-9aac-6868-1abd6554bb17@sysmocom.de>

Ok, with

sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -t 2 -c
~/.config/osmocom/osmo-bts-mtrx.cfg -d DRTP:DCC:DRSL:DL1C

it starts but phone fails to see the network - openbsc gives following
error:

<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 878
using MCC=1 MNC=64 LAC=1 CID=0 BSIC=63
<001d> input/ipa.c:265 accept()ed new link from 192.168.122.1 to port 3003
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/1) on ARFCN 880
using MCC=1 MNC=64 LAC=1 CID=0 BSIC=63
<0000> abis_rsl.c:1835 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION
cause=SABM frame with information not allowed in this state in state=ACTIVE
<0002> gsm_04_08.c:472 Subscriber 1640000005666: LOCATION UPDATING
REJECT LAC=1 BTS=0
<0002> gsm_subscriber.c:309 Subscriber 1640000005666 ATTACHED LAC=1
<001d> input/ipaccess.c:277 Bad signalling message,sign_link returned error
<001d> input/ipaccess.c:277 Bad signalling message,sign_link returned error
<0000> abis_rsl.c:1835 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION
cause=Timer T200 expired (N200+1) times in state=RELEASE REQUESTED

Could you share which versions/branches have you used in your tests?

Also could elaborate on '-m' - what's this option for and when it's
necessary? How it's support to affect osmo-bts configuration?


On 08/02/2016 12:39 AM, Tom Tsou wrote:
> Hi Max,
>
> On Mon, Aug 1, 2016 at 7:57 AM, Max <msuraev at sysmocom.de> wrote:
>> I've asked about it before but this seems to have been lost in
>> communication.
> I do not recall this discussion. My apologies.
>
>> The question is basically how to enable multi-TRX support for
>> osmo-bts-trx using phy/instance infrastructure similar to other bts?
> I use the following configuration.
>
> phy 0
>  instance 0
>  instance 1
>  osmotrx rx-gain 25
>
> bts 0
>  band 900
>  ipa unit-id 1234 0
>  oml remote-ip 127.0.0.1
>  settsc
>  gsmtap-sapi ccch
>  gsmtap-sapi pdtch
>  trx 0
>   phy 0 instance 0
>  trx 1
>   phy 0 instance 1
>
> $ osmo-bts-trx -c osmo-bts.cfg -t 2
>
>> In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
>> its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
>> correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
>> missing to make this actually work are greatly appreciated.
> You can use "osmo-trx -c 2" or "osmo-trx -m -c 2" to use dual-channels
> of the B210 or multi-ARFCN on one channel respectively.
>
> Note that there are ARFCN restrictions for both cases. Due to a shared
> local oscillator for both B210 channels, ARFCN separation can be up
> about 25 MHz.
>
> With multi-TRX, ARFCN spacing is fixed at 800 kHz or 4 GSM channels.
> So if TRX-0 is set to ARFCN 51, TRX-1 _must_ be set to 55. Up to three
> ARFCN's is supported for multi-TRX.
>
>   -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 tom at tsou.cc  Wed Aug 10 17:26:26 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 10 Aug 2016 10:26:26 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <aab35bd4-863b-adce-5ac1-d3594d62b77b@sysmocom.de>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <aab35bd4-863b-adce-5ac1-d3594d62b77b@sysmocom.de>
Message-ID: <CAATyM+ZF4sc+nOOhse7f-nhDK_19vGVXd5Xq1XESvkEqDO9Qtw@mail.gmail.com>

On Wed, Aug 10, 2016 at 6:42 AM, Max <msuraev at sysmocom.de> wrote:
> sudo chrt 20 ./Transceiver52M/osmo-trx -m -c 2 -g
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.004-0-unknown
>
...
> -- 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.

There is a UHD version requirement to clock the B200/B210 below 5 MHz,
which is preferred for timing reasons.

I am looking at the versioning. UHD master is obviously up to date.

  -TT


From tom at tsou.cc  Wed Aug 10 17:35:02 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 10 Aug 2016 10:35:02 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <fb6a2461-2567-9aac-6868-1abd6554bb17@sysmocom.de>
References: <fafb4970-1f4e-70f5-3c11-86b1f6a7c8e7@sysmocom.de>
 <CAATyM+Ztvgpzcs36TePJXzV4VujCYWDUsqqpaaVrBO5QcFgP5A@mail.gmail.com>
 <fb6a2461-2567-9aac-6868-1abd6554bb17@sysmocom.de>
Message-ID: <CAATyM+awARAERvFhjc0KYkCdaJ=oBj+Qk6arpdWwHrAWv8OnjA@mail.gmail.com>

On Wed, Aug 10, 2016 at 7:17 AM, Max <msuraev at sysmocom.de> wrote:
> <0002> gsm_subscriber.c:309 Subscriber 1640000005666 ATTACHED LAC=1
> <001d> input/ipaccess.c:277 Bad signalling message,sign_link returned error
> <001d> input/ipaccess.c:277 Bad signalling message,sign_link returned error
> <0000> abis_rsl.c:1835 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION
> cause=Timer T200 expired (N200+1) times in state=RELEASE REQUESTED
>
> Could you share which versions/branches have you used in your tests?

I was using master branch at the time. I will test with more recent
master branch updates later today.

> Also could elaborate on '-m' - what's this option for and when it's
> necessary? How it's support to affect osmo-bts configuration?

There are two ways to implement multi-ARFCN with the B210 - using
independent, direct channels for each ARFCN and mutiplexing multiple
ARFCN's onto a single RF channel.

The direct approach uses separate physical channels of the B210 (one
ARFCN each for side A and side B). Note that channels are not 100%
independent on the B210 because they share a single local oscillator
(LO). For that reason ARFCN channel separation is limited to roughly
25 MHz. This is the configuration if '-m' is not specified.

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.

Also note that the above configurations cannot be combined.

  -TT


From sipos.csaba at kvk.uni-obuda.hu  Wed Aug 10 18:08:14 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 10 Aug 2016 20:08:14 +0200 (CEST)
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+ZF4sc+nOOhse7f-nhDK_19vGVXd5Xq1XESvkEqDO9Qtw@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>
Message-ID: <1000115700.9468029.1470852494820.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Tom,

> 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

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Tom Tsou" <tom at tsou.cc>
C?mzett: "Max" <msuraev at sysmocom.de>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szerda, 2016. Augusztus 10. 19:26:26
T?rgy: Re: multiple phy with osmo-trx

On Wed, Aug 10, 2016 at 6:42 AM, Max <msuraev at sysmocom.de> wrote:
> sudo chrt 20 ./Transceiver52M/osmo-trx -m -c 2 -g
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.004-0-unknown
>
...
> -- 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.

There is a UHD version requirement to clock the B200/B210 below 5 MHz,
which is preferred for timing reasons.

I am looking at the versioning. UHD master is obviously up to date.

  -TT


From tom at tsou.cc  Thu Aug 11 02:14:05 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 10 Aug 2016 19:14:05 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <1000115700.9468029.1470852494820.JavaMail.zimbra@kvk.uni-obuda.hu>
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>
Message-ID: <CAATyM+aAq7qAP3OhMf14_7o7FkmrB9BCtKEp-UCov7J-yf+s=w@mail.gmail.com>

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


From msuraev at sysmocom.de  Thu Aug 11 09:50:42 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 11 Aug 2016 11:50:42 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+awARAERvFhjc0KYkCdaJ=oBj+Qk6arpdWwHrAWv8OnjA@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>
Message-ID: <b753ccad-39ed-7896-5b93-b4a2ea56700b@sysmocom.de>

Thanks for the explanation. See some comment inline.


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?

> 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?

>
>   -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 Aug 11 10:41:52 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 11 Aug 2016 12:41:52 +0200
Subject: revert policy?
Message-ID: <20160811104152.GA1562@dub7>

Hi list,

I'd like to gauge your opinions on how to handle reverts:

On the one hand, it is good to keep the revert as an exact reverse of the
original commit.

On the other hand, it may be good to include an in-code comment in the revert
to clarify the details for future readers. If both the revert and the comment
happen in the same commit, 'git blame' nicely shows that they are related.

I would tend towards keeping the revert "clean" and adding comments in a
separate commit -- how would you handle this?

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/20160811/34f56743/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Aug 11 14:14:16 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 11 Aug 2016 16:14:16 +0200
Subject: fyi, neels accounts mixup solved
Message-ID: <20160811141416.GB10531@dub7>

Today I've solved the recent weird mixup in gerrit of my main sysmocom account
"nhofmeyr" and my private mail address account "neels_test_account".

For some time now I've been marking my commits as neels at hofmeyr.de, which
should have been nhofmeyr at sysmocom.de. The config is now fixed in my various
git repositories and my future commits should be authored as nhofmeyr.

If you spot another neels at hofmeyr.de, that's a bug :)

~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/20160811/b68de32e/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Aug 11 18:41:38 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 11 Aug 2016 20:41:38 +0200
Subject: Error in making OsmoNITB on Linux
In-Reply-To: <CAFeMo5aUmszho1h_Pd-9CRETNTSDvieGu8FNXwjtK_YgKAwrtQ@mail.gmail.com>
References: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>
 <20160808174657.GA25602@dub7>
 <CAFeMo5aUmszho1h_Pd-9CRETNTSDvieGu8FNXwjtK_YgKAwrtQ@mail.gmail.com>
Message-ID: <20160811184138.GA30993@dub7>

On Wed, Aug 10, 2016 at 06:16:22PM +0100, Abdulghafar Shabaneh wrote:
> Hi Neels
> 
> I did build everything again and got the same error, I use git version
> 2.1.4
> there is no PROJECT in the git link you provided but I use the normal ones
> from

As with common shell scripting lingo, the "$PROJECT" was intended to be
replaced with the separate project names following below, and actually you've
done this correctly:

> git clone git://git.osmocom.org/libosmocore.git
> git clone git://git.osmocom.org/libosmo-abis.git
> git clone git://git.osmocom.org/libosmo-netif.git
> git clone git://git.osmocom.org/libosmo-sccp.git
> git clone git://git.osmocom.org/openggsn.git
> git clone git://git.osmocom.org/libsmpp34.git
> git clone git://git.osmocom.org/openbsc.git

I have verified that the build works on my raspberry. I must say it takes
impossibly long to build :)

My pi hasn't been upgraded in a long time (because that also takes impossibly
long). It is still on Debian 7.5.

Here are the things I did for a working build:

# make /usr/local owned by me, so I can install there without sudo
sudo chown -R $USER /usr/local

# install dependencies
sudo apt-get install automake build-essential gcc pkg-config libc-ares-dev libdbi-dev libpcap-dev libpcsclite-dev libsctp-dev libssl-dev libtalloc-dev libtool make libortp-dev libdbd-sqlite3

# make sure all the libraries will be found -- raspberry pi seems to not
# include /usr/local by default. Without this I get an error for openbsc's make
# check that the libosmo-abis.so.5 it not found, in the testsuite.log:
# (note that you have to do this in every shell you open, or include in your
# ~/.profile or something similar.)
export LD_LIBRARY_PATH=/usr/local/lib

# finally clone and build all projects as listed above.
git clone xxx
cd xxx
autoreconf -fi
./configure
make
make check
make install
cd ..

# For openbsc, you need to build in openbsc/openbsc, and I passed these config
# options:
./configure --enable-smpp --enable-osmo-bsc --enable-nat

Thus osmo-nitb works:

neels at raspberrypi ~/osmo/openbsc/openbsc/src/osmo-nitb $ ./osmo-nitb -c ../../doc/examples/osmo-nitb/sysmobts/openbsc.cfg 
<0005> bsc_init.c:498 VTY at 127.0.0.1 4242
<001d> input/ipaccess.c:838 enabling ipaccess BSC mode
<0016> smpp_smsc.c:978 SMPP at 0.0.0.0 2775
<0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249
DB: Database initialized.
DB: Database prepared.


> I have a text file for each of the terminal output but this is too long.
> Should I send them separately or in one long email. I'll ask in the list
> once you tell me.

If the above instructions still don't resolve the issue:

It would be sufficient to provide all the commands you have issued and the
(final) error message(s) produced. But to make sure that the juicy interesting
bits aren't missing, it's easiest to post it all.

Posting build output should not harm much; last time you posted a screenshot
image file of a small portion of build output, which easily exceeds the file
size of your complete build output in plain text format :)

You can also opt for using services like http://paste.lisp.org

Make sure you don't forget to include the commands you ran to start the build!

~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/20160811/52fce1f0/attachment.bin>

From tom at tsou.cc  Fri Aug 12 19:05:29 2016
From: tom at tsou.cc (Tom Tsou)
Date: Fri, 12 Aug 2016 12:05:29 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <b753ccad-39ed-7896-5b93-b4a2ea56700b@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>
Message-ID: <CAATyM+bJ61oUQPo2Fe=NK67uCOvZXLhp4YgcBzyYpGcMTaaLAA@mail.gmail.com>

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
-------------- next part --------------
=======================================
EGPRS and Multi-TRX Setup and Operation
=======================================

The following applications must be built, configured, and installed for EGPRS
support using the Osmocom stack and USRP radio device.

  1. openggsn
  2. osmo-sgsn
  3. openbsc (osmo-nitb)
  4. osmo-pcu
  5. osmo-bts
  6. osmo-trx

Operational notes are below.

  1. EGPRS and Multi-TRX Build
  2. EGPRS Configuration and Run
  3. Multi-TRX Configuration and Run



----------------------------
1. EGPRS and Multi-TRX Build
----------------------------

* openggsn *

Standard install.

  $ git clone git://git.osmocom.org/openggsn
  $ cd openggsn
  $ autoreconf -i
  $ ./configure
  $ make
  $ sudo make install


* openbsc *

Standard install and includes osmo-sgsn. Make sure that dependency c-ares and
gtp and libraries are detected. Otherwise, osmo-sgsn will not be built and
installed.

  $ git clone git://git.osmocom.org/openbsc
  $ cd openbsc
  $ autoreconf -i
  $ ./configure
  $ make
  $ sudo make install


* osmo-bts *

Non-standard install. OsmoBTS requires the EGPRS branch, which is not yet
merged into mainline. OsmoTRX also needs to be enabled at build time using
'--enable-trx'.

  $ git clone -b ttsou/egprs git://git.osmocom.org/osmo-bts 
  $ cd osmo-bts
  $ autoreconf -i
  $ ./configure --enable-trx
  $ make
  $ sudo make install


* osmo-pcu *

Standard install.

  $ git clone git//git.osmocom.org/osmo-pcu
  $ cd osmo-pcu
  $ autoreconf -i
  $ ./configure
  $ make
  $ sudo make install


* osmo-trx *

Standard install.

  $ git clone git//git.osmocom.org/osmo-trx
  $ cd osmo-trx
  $ autoreconf -i
  $ ./configure
  $ make
  $ sudo make install




--------------------------
2. EGPRS Configure and Run
--------------------------

* openbsc *

EGPRS support needs to be enabled in the OpenBSC configuration. The following
configuration sets up 1 transceiver with 6 PDCH channels and 1 full rate TCH
channel.

  openbsc.cfg
  --------------
  ! gprs section
  gprs mode egprs

  ! trx section
  trx 0
   rf_locked 0
   arfcn 51
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config CCCH+SDCCH4
     hopping enabled 0
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config PDCH
    timeslot 7
     phys_chan_config TCH/F

To run OpenBSC, start the osmo-nitb application.

  $ osmo-nitb -c openbsc.cfg


* osmo-bts *

There is no EGPRS or GPRS specific configuration in OsmoBTS. Start OsmoBTS with
the configuration file.

  $ osmo-bts-trx -c osmo-bts.cfg

 
* osmo-trx *

OsmoTRX needs to be configured from the command line to enable EGPRS modulation
support. The following command enables EDGE with additional options as described
below. There is no configuration file for OsmoTRX.

  $ sudo osmo-trx -e -l INFO -g

    -e         EDGE 8-PSK support
    -l INFO    Logging level INFO
    -g         GPS frequency reference


* osmo-pcu *

OsmoPCU configuration file needs to be modified for EGPRS. The following
lines enable EGPRS and MCS-4 and MCS-9 on the downlink and uplink respectively.

  osmo-pcu.cfg
  ------------
  pcu
   egprs only
    mcs 4 9

Start OsmoPCU from the command line with the configuration file.

  $ sudo osmo-pcu osmo-pcu.cfg


* osmo-sgsn *

There is no EGPRS or GPRS specific configuration for the SGSN.

  $ osmo-sgsn -c osmo-sgsn.cfg


* openggsn *

There is no EGPRS or GPRS specific configuration for the GGSN. The '-f' and '-d'
options set foreground operation and debug output respectively.

  $ sudo /usr/local/bin/ggsn -c ggsn.conf -f -d 




----------------------------------
3. Multi-TRX Configuration and Run
----------------------------------

* openbsc *

OpenBSC configuration file needs modification for multi-TRX operation. The
following TRX configuration sets up 3 transceivers with PDCH channels and a few
full rate TCH channels.

Important:

ARFCN values for trx 1 and 2 must be exactly 4 and 8 GSM channels higher than
the base frequency on trx 0. Because all channels are multiplexed onto a single
physical RF carrier, multi-TRX spacing between channels is 800 kHz and is not
configurable.

  openbsc-mc.cfg
  --------------
  trx 0
   rf_locked 0
   arfcn 51
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config CCCH+SDCCH4
     hopping enabled 0
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config PDCH
    timeslot 7
     phys_chan_config PDCH
  trx 1
   rf_locked 0
   arfcn 55
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config PDCH
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config PDCH
    timeslot 7
     phys_chan_config TCH/F
  trx 2
   rf_locked 0
   arfcn 59
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config PDCH
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config PDCH
    timeslot 7
     phys_chan_config TCH/F

To run OpenBSC with multi-TRX, start the osmo-nitb application normally.

  $ osmo-nitb -c openbsc.cfg


* osmo-bts *

OsmoBTS configuration file and command line change for multi-TRX operation. In
the configuration file, note the additional phy instance and trx lines.

  osmo-bts-mc.cfg
  ---------------
  phy 0
   instance 0
   instance 1
   instance 2
   osmotrx rx-gain 25
 
  bts 0
   band 900
   ipa unit-id 1234 0
   oml remote-ip 127.0.0.1
   settsc
   gsmtap-sapi ccch
   gsmtap-sapi pdtch
   trx 0
    phy 0 instance 0
   trx 1
    phy 0 instance 1
   trx 2
    phy 0 instance 2

The number of transceiver instances must also be specified on the command line.

  $ osmo-bts-trx -c osmo-bts-mc.cfg -t 3


* osmo-trx *

OsmoTRX needs to be configured from the command line for multi-TRX operation.
The following command enables multi-TRX and EDGE with additional options as
shown below.

  $ sudo osmo-trx -m -c 3 -e -l INFO -g

    -m         Multi-TRX
    -c 3       3 ARFCN channels
    -e         EDGE 8-PSK support
    -l INFO    Logging level INFO
    -g         GPS frequency reference


* osmo-pcu *

No change from single carrier operation.


* osmo-ggsn *

No change from single carrier operation.


* openggsn *

No change from single carrier operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ggsn.conf
Type: application/octet-stream
Size: 535 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc.cfg
Type: application/octet-stream
Size: 2543 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc-mc.cfg
Type: application/octet-stream
Size: 3393 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts.cfg
Type: application/octet-stream
Size: 615 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts-mc.cfg
Type: application/octet-stream
Size: 692 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-pcu.cfg
Type: application/octet-stream
Size: 245 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-sgsn.cfg
Type: application/octet-stream
Size: 1121 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160812/1832f17f/attachment-0006.obj>

From keith at rhizomatica.org  Fri Aug 12 20:33:33 2016
From: keith at rhizomatica.org (Keith Whyte)
Date: Fri, 12 Aug 2016 22:33:33 +0200
Subject: multiple phy with osmo-trx
In-Reply-To: <CAATyM+awARAERvFhjc0KYkCdaJ=oBj+Qk6arpdWwHrAWv8OnjA@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>
Message-ID: <1ca09648-1097-96ae-a838-83ef78e8fd83@rhizomatica.org>


On 10/08/2016 19:35, Tom Tsou wrote:
> There are two ways to implement multi-ARFCN with the B210 - using
> independent, direct channels for each ARFCN and mutiplexing multiple
> ARFCN's onto a single RF channel.
oo.. Possible silly question, but then is this multiplexing single RF
channel mode possible on the N210?

k/



From tom at tsou.cc  Fri Aug 12 21:07:06 2016
From: tom at tsou.cc (Tom Tsou)
Date: Fri, 12 Aug 2016 14:07:06 -0700
Subject: multiple phy with osmo-trx
In-Reply-To: <1ca09648-1097-96ae-a838-83ef78e8fd83@rhizomatica.org>
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>
 <1ca09648-1097-96ae-a838-83ef78e8fd83@rhizomatica.org>
Message-ID: <CAATyM+b7LBTKxb5NY=2qBdxst0SFdhfQzqivAzcLV4vNnOA1ww@mail.gmail.com>

On Fri, Aug 12, 2016 at 1:33 PM, Keith Whyte <keith at rhizomatica.org> wrote:
> On 10/08/2016 19:35, Tom Tsou wrote:
>> There are two ways to implement multi-ARFCN with the B210 - using
>> independent, direct channels for each ARFCN and mutiplexing multiple
>> ARFCN's onto a single RF channel.
> oo.. Possible silly question, but then is this multiplexing single RF
> channel mode possible on the N210?

Not a silly question at all. In fact, it's a very good question.

Yes and no. The N210 device is capable of operating in a similar
configuration, but the implementation is more complicated and, more
importantly, does not exist.

The reason is that the N210 uses a fixed FPGA clocking frequency that
doesn't match up well with the polyphase channelizer used for
multiplexing. The B200/B210 has configurable clocking so that the
desirable sampling rate for GSM channel spacing can be used.

  -TT


From holger at freyther.de  Mon Aug 15 18:09:47 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 15 Aug 2016 20:09:47 +0200
Subject: SS MM Messages (Call forwarding etc)
In-Reply-To: <FA3B247E-0A28-49F2-ADB8-1AB4135EB273@freyther.de>
References: <02c1ee83-ec65-7cb2-a597-ea0dfbe12411@rhizomatica.org>
 <F7031AAC-5A99-46C7-9BDE-BC54E2715346@freyther.de>
 <577BF2DE.3070700@rhizomatica.org>
 <47DF1FB6-0D3D-488D-8C98-BDF6DEC55149@freyther.de>
 <FA3B247E-0A28-49F2-ADB8-1AB4135EB273@freyther.de>
Message-ID: <90543C75-5802-4692-B73A-1F599CC3D4C5@freyther.de>


> On 12 Jul 2016, at 18:03, Holger Freyther <holger at freyther.de> wrote:
> 


Dear Keith,


> can you please fetch this change https://gerrit.osmocom.org/503? The main issue is that our USSD/SS decoding does not distinguish between the ROS part (invoke, reject, return, returnLast) but is guessing about results or notifications based on having a "string". In case of interrogate SS there is no text..
> 
> feel free to either update the gerrit review or this ticket to see if this works. My BTS is still boxed so I did not try the resulting code myself.


time flies. The first patch identified the right lines, and approach but neither compiled nor was correct. Could you give it a try with the new one pushed to gerrit? It does compile and I will give it a try in a virtual environment now. :)

holger

From abdulghafar1412 at gmail.com  Tue Aug 16 14:07:08 2016
From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh)
Date: Tue, 16 Aug 2016 15:07:08 +0100
Subject: Error in making OsmoNITB on Linux
In-Reply-To: <20160811184138.GA30993@dub7>
References: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>
 <20160808174657.GA25602@dub7>
 <CAFeMo5aUmszho1h_Pd-9CRETNTSDvieGu8FNXwjtK_YgKAwrtQ@mail.gmail.com>
 <20160811184138.GA30993@dub7>
Message-ID: <CAFeMo5bHqeW+moqJAaVjF2Om8HMqiOm4T69BLT5PrrX1kAMNEA@mail.gmail.com>

Hi

How do you include /usr/local by default. Which command is used to do it. I
managed to install all projects except the openbsc.

I post here the openbsc make and make check errors.

pi at dwarfabd:~ $ cd openbsc/openbsc
pi at dwarfabd:~/openbsc/openbsc $ autoreconf -fi
tests/bsc-nat-trie/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite_trie.c' is in a
subdirectory,
tests/bsc-nat-trie/Makefile.am:9: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding
output
automake: object file(s) will be placed in the top-level directory.
However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout
your
automake: project, to avoid future incompatibilities.
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_filter.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_sccp.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_nat_utils.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_nat_filter.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite_trie.c' is in a
subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc-nat/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc_nat/bsc_mgcp_utils.c' is in a subdirectory,
tests/bsc-nat/Makefile.am:9: but option 'subdir-objects' is disabled
tests/bsc/Makefile.am:9: warning: source file
'$(top_srcdir)/src/osmo-bsc/osmo_bsc_filter.c' is in a subdirectory,
tests/bsc/Makefile.am:9: but option 'subdir-objects' is disabled
tests/smpp/Makefile.am:9: warning: source file
'$(top_builddir)/src/libmsc/smpp_utils.c' is in a subdirectory,
tests/smpp/Makefile.am:9: but option 'subdir-objects' is disabled

####################################################################################################
pi at dwarfabd:~/openbsc/openbsc $ ./configure --enable-smpp --enable-osmo-bsc
--enable-nat
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for library containing crypt... -lcrypt
checking for library containing dlopen... -ldl
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOABIS... yes
checking for LIBOSMOGB... yes
checking for LIBOSMOSCCP... yes
checking for LIBOSMOSCCP... yes
checking for LIBSMPP34... yes
checking for LIBGTP... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dahdi/user.h usability... no
checking dahdi/user.h presence... no
checking for dahdi/user.h... no
configure: WARNING: DAHDI input driver will not be built
checking dbi/dbd.h usability... yes
checking dbi/dbd.h presence... yes
checking for dbi/dbd.h... yes
checking if gcc supports -fvisibility=hidden... yes
checking whether to enable code coverage support... no
checking whether struct tm has tm_gmtoff member... yes
checking whether to enable VTY tests... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating openbsc.pc
config.status: creating include/openbsc/Makefile
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating src/libtrau/Makefile
config.status: creating src/libbsc/Makefile
config.status: creating src/libctrl/Makefile
config.status: creating src/libmsc/Makefile
config.status: creating src/libmgcp/Makefile
config.status: creating src/libcommon/Makefile
config.status: creating src/osmo-nitb/Makefile
config.status: creating src/osmo-bsc/Makefile
config.status: creating src/osmo-bsc_nat/Makefile
config.status: creating src/osmo-bsc_mgcp/Makefile
config.status: creating src/ipaccess/Makefile
config.status: creating src/utils/Makefile
config.status: creating src/gprs/Makefile
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating tests/gsm0408/Makefile
config.status: creating tests/db/Makefile
config.status: creating tests/channel/Makefile
config.status: creating tests/bsc/Makefile
config.status: creating tests/bsc-nat/Makefile
config.status: creating tests/bsc-nat-trie/Makefile
config.status: creating tests/mgcp/Makefile
config.status: creating tests/gprs/Makefile
config.status: creating tests/gbproxy/Makefile
config.status: creating tests/abis/Makefile
config.status: creating tests/smpp/Makefile
config.status: creating tests/trau/Makefile
config.status: creating doc/Makefile
config.status: creating doc/examples/Makefile
config.status: creating Makefile
config.status: creating bscconfig.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
################################################################################
pi at dwarfabd:~/openbsc/openbsc $ make
make  all-recursive
make[1]: Entering directory '/home/pi/openbsc/openbsc'
Making all in doc
make[2]: Entering directory '/home/pi/openbsc/openbsc/doc'
Making all in examples
make[3]: Entering directory '/home/pi/openbsc/openbsc/doc/examples'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/doc/examples'
make[3]: Entering directory '/home/pi/openbsc/openbsc/doc'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/doc'
make[2]: Leaving directory '/home/pi/openbsc/openbsc/doc'
Making all in include
make[2]: Entering directory '/home/pi/openbsc/openbsc/include'
Making all in openbsc
make[3]: Entering directory '/home/pi/openbsc/openbsc/include/openbsc'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/include/openbsc'
make[3]: Entering directory '/home/pi/openbsc/openbsc/include'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/include'
make[2]: Leaving directory '/home/pi/openbsc/openbsc/include'
Making all in src
make[2]: Entering directory '/home/pi/openbsc/openbsc/src'
Making all in libcommon
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libcommon'
  CC       bsc_version.o
  AR       libcommon.a
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libcommon'
Making all in libmgcp
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libmgcp'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libmgcp'
Making all in libbsc
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libbsc'
  CC       bts_ipaccess_nanobts.o
bts_ipaccess_nanobts.c: In function ?ipaccess_sign_link_up?:
bts_ipaccess_nanobts.c:577:42: error: dereferencing pointer to incomplete
type
  bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
                                          ^
bts_ipaccess_nanobts.c:577:56: error: dereferencing pointer to incomplete
type
  bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
                                                        ^
In file included from ../../include/openbsc/debug.h:8:0,
                 from bts_ipaccess_nanobts.c:36:
bts_ipaccess_nanobts.c:580:37: error: dereferencing pointer to incomplete
type
    " %u/%u/%u, disconnecting\n", dev->site_id,
                                     ^
bts_ipaccess_nanobts.c:581:7: error: dereferencing pointer to incomplete
type
    dev->bts_id, dev->trx_id);
       ^
bts_ipaccess_nanobts.c:581:20: error: dereferencing pointer to incomplete
type
    dev->bts_id, dev->trx_id);
                    ^
bts_ipaccess_nanobts.c:585:7: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
       ^
bts_ipaccess_nanobts.c:585:21: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
                     ^
bts_ipaccess_nanobts.c:585:34: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
                                  ^
bts_ipaccess_nanobts.c:600:53: error: dereferencing pointer to incomplete
type
   struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, dev->trx_id);
                                                     ^
bts_ipaccess_nanobts.c:611:38: error: dereferencing pointer to incomplete
type
   ts = &line->ts[E1INP_SIGN_RSL + dev->trx_id - 1];
                                      ^
Makefile:398: recipe for target 'bts_ipaccess_nanobts.o' failed
make[3]: *** [bts_ipaccess_nanobts.o] Error 1
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libbsc'
Makefile:346: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/pi/openbsc/openbsc/src'
Makefile:437: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/pi/openbsc/openbsc'
Makefile:354: recipe for target 'all' failed
make: *** [all] Error 2
##########################################################################
pi at dwarfabd:~/openbsc/openbsc $ make check
make  check-recursive
make[1]: Entering directory '/home/pi/openbsc/openbsc'
Making check in doc
make[2]: Entering directory '/home/pi/openbsc/openbsc/doc'
Making check in examples
make[3]: Entering directory '/home/pi/openbsc/openbsc/doc/examples'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/doc/examples'
make[3]: Entering directory '/home/pi/openbsc/openbsc/doc'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/doc'
make[2]: Leaving directory '/home/pi/openbsc/openbsc/doc'
Making check in include
make[2]: Entering directory '/home/pi/openbsc/openbsc/include'
Making check in openbsc
make[3]: Entering directory '/home/pi/openbsc/openbsc/include/openbsc'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/include/openbsc'
make[3]: Entering directory '/home/pi/openbsc/openbsc/include'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/include'
make[2]: Leaving directory '/home/pi/openbsc/openbsc/include'
Making check in src
make[2]: Entering directory '/home/pi/openbsc/openbsc/src'
Making check in libcommon
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libcommon'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libcommon'
Making check in libmgcp
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libmgcp'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libmgcp'
Making check in libbsc
make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libbsc'
  CC       bts_ipaccess_nanobts.o
bts_ipaccess_nanobts.c: In function ?ipaccess_sign_link_up?:
bts_ipaccess_nanobts.c:577:42: error: dereferencing pointer to incomplete
type
  bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
                                          ^
bts_ipaccess_nanobts.c:577:56: error: dereferencing pointer to incomplete
type
  bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
                                                        ^
In file included from ../../include/openbsc/debug.h:8:0,
                 from bts_ipaccess_nanobts.c:36:
bts_ipaccess_nanobts.c:580:37: error: dereferencing pointer to incomplete
type
    " %u/%u/%u, disconnecting\n", dev->site_id,
                                     ^
bts_ipaccess_nanobts.c:581:7: error: dereferencing pointer to incomplete
type
    dev->bts_id, dev->trx_id);
       ^
bts_ipaccess_nanobts.c:581:20: error: dereferencing pointer to incomplete
type
    dev->bts_id, dev->trx_id);
                    ^
bts_ipaccess_nanobts.c:585:7: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
       ^
bts_ipaccess_nanobts.c:585:21: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
                     ^
bts_ipaccess_nanobts.c:585:34: error: dereferencing pointer to incomplete
type
    dev->site_id, dev->bts_id, dev->trx_id);
                                  ^
bts_ipaccess_nanobts.c:600:53: error: dereferencing pointer to incomplete
type
   struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, dev->trx_id);
                                                     ^
bts_ipaccess_nanobts.c:611:38: error: dereferencing pointer to incomplete
type
   ts = &line->ts[E1INP_SIGN_RSL + dev->trx_id - 1];
                                      ^
Makefile:398: recipe for target 'bts_ipaccess_nanobts.o' failed
make[3]: *** [bts_ipaccess_nanobts.o] Error 1
make[3]: Leaving directory '/home/pi/openbsc/openbsc/src/libbsc'
Makefile:346: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/home/pi/openbsc/openbsc/src'
Makefile:437: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/pi/openbsc/openbsc'
Makefile:728: recipe for target 'check' failed
make: *** [check] Error 2

Thanks
Abdulghafar


On Thu, Aug 11, 2016 at 7:41 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Wed, Aug 10, 2016 at 06:16:22PM +0100, Abdulghafar Shabaneh wrote:
> > Hi Neels
> >
> > I did build everything again and got the same error, I use git version
> > 2.1.4
> > there is no PROJECT in the git link you provided but I use the normal
> ones
> > from
>
> As with common shell scripting lingo, the "$PROJECT" was intended to be
> replaced with the separate project names following below, and actually
> you've
> done this correctly:
>
> > git clone git://git.osmocom.org/libosmocore.git
> > git clone git://git.osmocom.org/libosmo-abis.git
> > git clone git://git.osmocom.org/libosmo-netif.git
> > git clone git://git.osmocom.org/libosmo-sccp.git
> > git clone git://git.osmocom.org/openggsn.git
> > git clone git://git.osmocom.org/libsmpp34.git
> > git clone git://git.osmocom.org/openbsc.git
>
> I have verified that the build works on my raspberry. I must say it takes
> impossibly long to build :)
>
> My pi hasn't been upgraded in a long time (because that also takes
> impossibly
> long). It is still on Debian 7.5.
>
> Here are the things I did for a working build:
>
> # make /usr/local owned by me, so I can install there without sudo
> sudo chown -R $USER /usr/local
>
> # install dependencies
> sudo apt-get install automake build-essential gcc pkg-config libc-ares-dev
> libdbi-dev libpcap-dev libpcsclite-dev libsctp-dev libssl-dev libtalloc-dev
> libtool make libortp-dev libdbd-sqlite3
>
> # make sure all the libraries will be found -- raspberry pi seems to not
> # include /usr/local by default. Without this I get an error for openbsc's
> make
> # check that the libosmo-abis.so.5 it not found, in the testsuite.log:
> # (note that you have to do this in every shell you open, or include in
> your
> # ~/.profile or something similar.)
> export LD_LIBRARY_PATH=/usr/local/lib
>
> # finally clone and build all projects as listed above.
> git clone xxx
> cd xxx
> autoreconf -fi
> ./configure
> make
> make check
> make install
> cd ..
>
> # For openbsc, you need to build in openbsc/openbsc, and I passed these
> config
> # options:
> ./configure --enable-smpp --enable-osmo-bsc --enable-nat
>
> Thus osmo-nitb works:
>
> neels at raspberrypi ~/osmo/openbsc/openbsc/src/osmo-nitb $ ./osmo-nitb -c
> ../../doc/examples/osmo-nitb/sysmobts/openbsc.cfg
> <0005> bsc_init.c:498 VTY at 127.0.0.1 4242
> <001d> input/ipaccess.c:838 enabling ipaccess BSC mode
> <0016> smpp_smsc.c:978 SMPP at 0.0.0.0 2775
> <0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249
> DB: Database initialized.
> DB: Database prepared.
>
>
> > I have a text file for each of the terminal output but this is too long.
> > Should I send them separately or in one long email. I'll ask in the list
> > once you tell me.
>
> If the above instructions still don't resolve the issue:
>
> It would be sufficient to provide all the commands you have issued and the
> (final) error message(s) produced. But to make sure that the juicy
> interesting
> bits aren't missing, it's easiest to post it all.
>
> Posting build output should not harm much; last time you posted a
> screenshot
> image file of a small portion of build output, which easily exceeds the
> file
> size of your complete build output in plain text format :)
>
> You can also opt for using services like http://paste.lisp.org
>
> Make sure you don't forget to include the commands you ran to start the
> build!
>
> ~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/20160816/6b8e6581/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Aug 17 10:24:17 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 17 Aug 2016 12:24:17 +0200
Subject: multiline comment style?
Message-ID: <20160817102417.GA1556@dub7>

Hi list,

I've now heard two conflicting instructions on multi-line comments in osmocom
code; I'd like this clarified, which is the preferred multiline comment style?

From Holger, first hand:

/*
 * multi
 * line
 */

vs. from Harald (?), via hearsay:

/* multi
 * line */

The first is easier to edit, while the last takes up less space...
I always used the shorter one until Holger told me to expand.

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/20160817/a6839f75/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Aug 17 10:56:31 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 17 Aug 2016 12:56:31 +0200
Subject: Error in making OsmoNITB on Linux
In-Reply-To: <CAFeMo5bHqeW+moqJAaVjF2Om8HMqiOm4T69BLT5PrrX1kAMNEA@mail.gmail.com>
References: <CAFeMo5ZK45yLX28Zkv0zQ6pmye9bMvsa=-fQ8hHk9groLFYjbA@mail.gmail.com>
 <20160808174657.GA25602@dub7>
 <CAFeMo5aUmszho1h_Pd-9CRETNTSDvieGu8FNXwjtK_YgKAwrtQ@mail.gmail.com>
 <20160811184138.GA30993@dub7>
 <CAFeMo5bHqeW+moqJAaVjF2Om8HMqiOm4T69BLT5PrrX1kAMNEA@mail.gmail.com>
Message-ID: <20160817105631.GB1556@dub7>

On Tue, Aug 16, 2016 at 03:07:08PM +0100, Abdulghafar Shabaneh wrote:
> Hi
> 
> How do you include /usr/local by default. Which command is used to do it.

It was right there in my mail:

> # make sure all the libraries will be found -- raspberry pi seems to not
> # include /usr/local by default. Without this I get an error for openbsc's
> make
> # check that the libosmo-abis.so.5 it not found, in the testsuite.log:
> # (note that you have to do this in every shell you open, or include in
> your
> # ~/.profile or something similar.)
> export LD_LIBRARY_PATH=/usr/local/lib

By setting the LD_LIBRARY_PATH environment you tell the linker to look for
installed libraries in /usr/local/lib.  You need to do this in the same
terminal that you use to build openbsc. This is very general build knowledge
and I am starting to repeat myself -- please consult your favorite search
engine on LD_LIBRARY_PATH...

Anyway, you are getting an error that I don't see:

> Making all in libbsc
> make[3]: Entering directory '/home/pi/openbsc/openbsc/src/libbsc'
>   CC       bts_ipaccess_nanobts.o
> bts_ipaccess_nanobts.c: In function ?ipaccess_sign_link_up?:
> bts_ipaccess_nanobts.c:577:42: error: dereferencing pointer to incomplete
> type
>   bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
>                                           ^
> bts_ipaccess_nanobts.c:577:56: error: dereferencing pointer to incomplete
> type
>   bts = find_bts_by_unitid(bsc_gsmnet, dev->site_id, dev->bts_id);
>                                                         ^

As I said before, the 'dev' is a struct ipaccess_unit*, and it should
definitely not be an icomplete type. If the file were missing, the compiler
would complain.

You could verify that your osmocom/gsm/ipa.h file includes the definition of
struct ipaccess_unit like this:

struct ipaccess_unit {
        uint16_t site_id;
        uint16_t bts_id;
        uint16_t trx_id;
        char *unit_name;
        char *equipvers;
        char *swversion;
        uint8_t mac_addr[6];
        char *location1;
        char *location2;
        char *serno;
};

Check both in your git clone and what it looks like in
/usr/local/include/osmocom/gsm/ipa.h.

I can't think of any reason why it shouldn't be there if you have indeed
checked out the newest osmocom without local modifications, except maybe that
your disk is full and the header files cannot be written to disk?

Another way to fix this issue might be to 'make uninstall' and rebuild from
scratch, this time with each ./configure adding a prefix arg,
and use root privileges for the install step:

  ./configure --prefix=/usr [...]
  make
  make check
  sudo make install

This way things get installed in /usr and no special measures for /usr/local
should be needed.

In any case, this is all I can do for you from over here. It seems to be a
general problem not related to osmocom specifically.

I hope to have provided enough leads for you to fix it ... it definitely works,
don't give up and let us know of your progress :)

~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/20160817/b2af64fd/attachment.bin>

From keith at rhizomatica.org  Wed Aug 17 11:11:50 2016
From: keith at rhizomatica.org (Keith)
Date: Wed, 17 Aug 2016 13:11:50 +0200
Subject: lchan broken unusable activation timeout
Message-ID: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>

Hi all

In some communities we are using 5Ghz wifi links between the box running
openBSC and the sbts2050.

In often works well for some time, but then we get plagued with
BROKEN_UNUSABLE channels:
I cannot say exactly why, probably rain, solar radiation, aliens,
goblins.. etc.
I have yet to actually be able to watch it happen. I usually just
discover the problem, correct it and then it works fine until I get
bored watching.

BTS 1, TRX 0, Timeslot 1, Lchan 2: Type NONE
  Connection: 0, State: BROKEN UNUSABLE Error reason: activation timeout

This requires then either

A) use the drop command in the vty
B) restart the osmo-bts process on the 2050 (same thing as A really)
C) restart osmo-nitb

All these things are ugly, as they will drop other calls on the BTS at
the time.

The question is, would somebody help make this more robust, as in have
it self repair?

Initial questions:

Why does the broken unusable channel stay as such until manual intervention,
Is is just because the code has not been written to monitor and recover,
or is there some other reason?
I am thinking that nobody ever did this, probably all testing and
installation has been done using nice reliable cabled ethernet and not
ugly nasty packet dropping 3km wifi links. :-)

Thanks!









From holger at freyther.de  Wed Aug 17 11:22:12 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 17 Aug 2016 13:22:12 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
Message-ID: <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>


> On 17 Aug 2016, at 13:11, Keith <keith at rhizomatica.org> wrote:
> 



> Initial questions:
> 
> Why does the broken unusable channel stay as such until manual intervention,
> Is is just because the code has not been written to monitor and recover,
> or is there some other reason?
> I am thinking that nobody ever did this, probably all testing and
> installation has been done using nice reliable cabled ethernet and not
> ugly nasty packet dropping 3km wifi links. :-)

A RF Channel Release NACKed, or two responses or no response. With equipment like a nanoBTS you just don't know what the state of the channel is.


        /*
         * The BTS didn't respond within the timeout to our channel
         * release request and we have marked the channel as broken.
         * Now we do receive an ACK and let's be conservative. If it
         * is a sysmoBTS we know that only one RF Channel Release ACK
         * will be sent. So let's "repair" the channel.
         */
        if (lchan->state == LCHAN_S_BROKEN) {
                int do_free = is_sysmobts_v2(lchan->ts->trx->bts);
                LOGP(DRSL, LOGL_NOTICE,
                        "%s CHAN REL ACK for broken channel. %s.\n",
                        gsm_lchan_name(lchan),
                        do_free ? "Releasing it" : "Keeping it broken");
                if (do_free)
                        do_lchan_free(lchan);
                return 0;
        }


so I assume you want to put "type sysmobts" into the OpenBSC config. IIRC I added that specially for Rhizomatica.


cheers
	holger

From keith at rhizomatica.org  Wed Aug 17 11:34:13 2016
From: keith at rhizomatica.org (Keith)
Date: Wed, 17 Aug 2016 13:34:13 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
Message-ID: <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>



On 17/08/2016 13:22, Holger Freyther wrote:
> so I assume you want to put "type sysmobts" into the OpenBSC config. IIRC I added that specially for Rhizomatica.
It's there.
So, something else is up.
I will try to get some more data to work with. I'm thinking the best
thing to do is setup a lab using tc or something to mimic the nasty wifi
link.

Thanks!


From tom at tsou.cc  Wed Aug 17 17:45:47 2016
From: tom at tsou.cc (Tom Tsou)
Date: Wed, 17 Aug 2016 10:45:47 -0700
Subject: multiline comment style?
In-Reply-To: <20160817102417.GA1556@dub7>
References: <20160817102417.GA1556@dub7>
Message-ID: <CAATyM+bBi5VM2yZOXafoxfLjv0-GHewVB6BevzMC1S34e10sJg@mail.gmail.com>

On Wed, Aug 17, 2016 at 3:24 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> I've now heard two conflicting instructions on multi-line comments in osmocom
> code; I'd like this clarified, which is the preferred multiline comment style?

I have noticed these differences in the code and thought about it too.

> From Holger, first hand:
>
> /*
>  * multi
>  * line
>  */

Holger's approach is the general style according to the Linux kernel
coding style. That is the reference point that I have used.

https://www.kernel.org/doc/Documentation/CodingStyle

> vs. from Harald (?), via hearsay:
>
> /* multi
>  * line */

This is a modified form of the net/ and drivers/net style of the Linux
kernel where the comment close is on the same vs. separate lines.

/* multi
 * line
 */

I prefer Holger's comment style, however, I have limited say in this battle.

  -TT


From holger at freyther.de  Wed Aug 17 19:43:00 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 17 Aug 2016 21:43:00 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
Message-ID: <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>


> On 17 Aug 2016, at 13:34, Keith <keith at rhizomatica.org> wrote:
> 
> 
> 
> On 17/08/2016 13:22, Holger Freyther wrote:
>> so I assume you want to put "type sysmobts" into the OpenBSC config. IIRC I added that specially for Rhizomatica.
> It's there.
> So, something else is up.
> I will try to get some more data to work with. I'm thinking the best
> thing to do is setup a lab using tc or something to mimic the nasty wifi
> link.


Maybe not the version of osmo-bts you run but I think later versions mark channels as broken as well (e.g. if the DSP did something odd).

*If* the channel release ack (or activation) is just delayed it should clean-up properly if "type sysmobts" is set in the config.


holger

From keith at rhizomatica.org  Wed Aug 17 20:27:30 2016
From: keith at rhizomatica.org (Keith)
Date: Wed, 17 Aug 2016 22:27:30 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
Message-ID: <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>



On 17/08/2016 21:43, Holger Freyther wrote:
> Maybe not the version of osmo-bts you run but I think later versions
> mark channels as broken as well (e.g. if the DSP did something odd).
> *If* the channel release ack (or activation) is just delayed it should clean-up properly if "type sysmobts" is set in the config.
type sysmobts is set in the config.
Unfortunately, in a new installation
(https://twitter.com/ninalakhani/status/765250788046143488) with a wifi
link of some 3 KM or so
we are ending up with this kind of situation after a short time:

OpenBSC# show lchan su
BTS 0, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl: -101 dBm RXL-FULL-ul: -104 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 1, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 2, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 3, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 4, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 5, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 6, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1, Lchan 7, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl: -104 dBm RXL-FULL-ul: -106 dBm
BTS 0, TRX 0, Timeslot 2, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 3, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 4, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 5, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 6, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -87 dBm RXL-FULL-ul:  -91 dBm
BTS 0, TRX 0, Timeslot 7, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 1, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -87 dBm RXL-FULL-ul:  -95 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 2, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 3, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -78 dBm RXL-FULL-ul:  -82 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 4, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 5, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl: -101 dBm RXL-FULL-ul:  -98 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 6, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 1, Lchan 7, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -96 dBm RXL-FULL-ul:  -95 dBm
BTS 1, TRX 0, Timeslot 3, Lchan 0, Type NONE - L1 MS Power: 0 dBm
RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 1, TRX 0, Timeslot 4, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -75 dBm RXL-FULL-ul:  -83 dBm
BTS 1, TRX 0, Timeslot 5, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -93 dBm RXL-FULL-ul:  -94 dBm
BTS 1, TRX 0, Timeslot 6, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -95 dBm RXL-FULL-ul: -105 dBm
BTS 1, TRX 0, Timeslot 7, Lchan 0, Type NONE - L1 MS Power: 33 dBm
RXL-FULL-dl:  -78 dBm RXL-FULL-ul:  -77 dBm

During all the much time I have been watching LOG output, I cannot
recall ever having seen:
CHAN REL ACK for broken channel. Releasing it
nor:
CHAN REL ACK for broken channel. Keeping it broken

Can I ask, What triggers the eventual calling of
rsl_rx_rf_chan_rel_ack(), (I tried to trace it back but get a bit lost.)
I do not understand the logic, as it would seem that once the REL ACK is
lost, then it is lost, right?
It would seem that something in openBSC needs to check for broken
channels and release them. But then.. my understanding here is limited.

Any help very much appreciated
>
> holger



From laforge at gnumonks.org  Wed Aug 17 21:15:39 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 17 Aug 2016 23:15:39 +0200
Subject: revert policy?
In-Reply-To: <20160811104152.GA1562@dub7>
References: <20160811104152.GA1562@dub7>
Message-ID: <20160817211539.l2wsbypnc2m7yhd5@nataraja>

Hi Neels,

On Thu, Aug 11, 2016 at 12:41:52PM +0200, Neels Hofmeyr wrote:

> I would tend towards keeping the revert "clean" and adding comments in a
> separate commit -- how would you handle this?

I don't really care, no preference either way.

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


From holger at freyther.de  Wed Aug 17 21:35:44 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 17 Aug 2016 23:35:44 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
Message-ID: <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>


> On 17 Aug 2016, at 22:27, Keith <keith at rhizomatica.org> wrote:
> 
> 
> 
> On 17/08/2016 21:43, Holger Freyther wrote:
>> Maybe not the version of osmo-bts you run but I think later versions
>> mark channels as broken as well (e.g. if the DSP did something odd).
>> *If* the channel release ack (or activation) is just delayed it should clean-up properly if "type sysmobts" is set in the config.
> type sysmobts is set in the config.
> Unfortunately, in a new installation
> (https://twitter.com/ninalakhani/status/765250788046143488) with a wifi
> link of some 3 KM or so
> we are ending up with this kind of situation after a short time:
> 
> OpenBSC# show lchan su
> BTS 0, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 33 dBm

type none? What OpenBSC version is that? So just the none already looks broken.


> Can I ask, What triggers the eventual calling of
> rsl_rx_rf_chan_rel_ack(), (I tried to trace it back but get a bit lost.)
> I do not understand the logic, as it would seem that once the REL ACK is
> lost, then it is lost, right?
> It would seem that something in openBSC needs to check for broken
> channels and release them. But then.. my understanding here is limited.


the actual arrival of the REL_ACK message.

holger

From holger at freyther.de  Wed Aug 17 21:52:31 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 17 Aug 2016 23:52:31 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
 <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
Message-ID: <782143EB-AF08-4549-9802-2E8690DBEE37@freyther.de>


> On 17 Aug 2016, at 23:35, Holger Freyther <holger at freyther.de> wrote:
> 
>> 
>> OpenBSC# show lchan su
>> BTS 0, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 33 dBm
> 
> type none? What OpenBSC version is that? So just the none already looks broken.

So please do the following for reference:

* Create a ticket in the Osmocom tracker
* List libosmocore/libosmo-abis/../OpenBSC/osmo-bts git commit (+patches if it makes sense)
* Attach both BTS and NITB config
* PCAP file (if it doesn't include personal data, otherwise try to pseudomize it or share out of band).


thank you
	holger

From keith at rhizomatica.org  Wed Aug 17 22:28:38 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 18 Aug 2016 00:28:38 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <782143EB-AF08-4549-9802-2E8690DBEE37@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
 <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
 <782143EB-AF08-4549-9802-2E8690DBEE37@freyther.de>
Message-ID: <1f28fcbe-54c4-0137-cff2-ff171f535289@rhizomatica.org>


On 17/08/2016 23:52, Holger Freyther wrote:
> So please do the following for reference:
>
> * Create a ticket in the Osmocom tracker
OK
> * List libosmocore/libosmo-abis/../OpenBSC/osmo-bts git commit (+patches if it makes sense)
Unknown, as I didn't build it, but we could dispense with this, and I
can just compile from a know good/recent commit and go from there.
> * Attach both BTS and NITB config
> * PCAP file (if it doesn't include personal data, otherwise try to pseudomize it or share out of band).
>
I think specifically a capture of the point at which this kind of thing
starts to happen would be the interesting part, although I have to sit
around for a while to get it. Not sure how to filter then the resulting
pcap to just that part but I'll figure it out.

<0004> abis_rsl.c:630 (bts=1,trx=0,ts=1,ss=0) is back in operation.
<0004> abis_rsl.c:615 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1102 (bts=0,trx=0,ts=1,ss=0): MEAS RES for inactive
channel
<0004> abis_rsl.c:1330 (bts=0,trx=0,ts=1,ss=0) SACCH deactivation timeout.
<0004> abis_rsl.c:661 (bts=0,trx=0,ts=1,ss=0) RF Channel Release CMD due
error 1
<0004> abis_rsl.c:1102 (bts=0,trx=0,ts=1,ss=0): MEAS RES for inactive
channel
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=1,ss=0) Timeout during
deactivation! Marked as broken.

now, Just as soon as what I said in a previous mail about not having
seen it, those rsl log entries are followed by

<0004> abis_rsl.c:717 (bts=0,trx=0,ts=1,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=1,ss=0) CHAN REL ACK for broken
channel. Releasing it.

However, this follows in the log and these remain broken "forever"

<0004> abis_rsl.c:1198 (bts=0,trx=0,ts=1,ss=1) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:949 (bts=0,trx=0,ts=1,ss=1) CHAN ACT ACK for broken
channel.
<0004> abis_rsl.c:1198 (bts=0,trx=0,ts=1,ss=2) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:949 (bts=0,trx=0,ts=1,ss=2) CHAN ACT ACK for broken
channel.
<0004> abis_rsl.c:1198 (bts=0,trx=0,ts=1,ss=3) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:949 (bts=0,trx=0,ts=1,ss=3) CHAN ACT ACK for broken
channel.
<0004> abis_rsl.c:1198 (bts=0,trx=0,ts=1,ss=4) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:949 (bts=0,trx=0,ts=1,ss=4) CHAN ACT ACK for broken
channel.



From keith at rhizomatica.org  Wed Aug 17 22:46:55 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 18 Aug 2016 00:46:55 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
 <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
Message-ID: <d17b596e-6b1b-9bb0-4bc4-4ae83c43f62e@rhizomatica.org>


On 17/08/2016 23:35, Holger Freyther wrote:
>> OpenBSC# show lchan su
>> BTS 0, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 33 dBm
> type none? What OpenBSC version is that? So just the none already looks broken.
Sure, If you look at the non summary version of lchan, you see the likes of
BTS 1, TRX 0, Timeslot 7, Lchan 0: Type NONE
  Connection: 0, State: BROKEN UNUSABLE Error reason: activation timeout
  BS Power: 37 dBm, MS Power: 33 dBm
  No Subscriber
  Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0
  Measurement Report:
    Flags: DLinval
    RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0,
RXQ-SUB-ul: 0
osmo-nitb tells me it is
OpenBSC version 0.14.0-dirty

You mentioned off list about the sbts2050 software, yes I'm afraid it's
201208-testing.
>> Can I ask, What triggers the eventual calling of
>> rsl_rx_rf_chan_rel_ack(), 
> the actual arrival of the REL_ACK message.
So it won't ever be called, once it's "lost"
What I don't understand is how it can get lost. Or arrive out of order
of something, that's not possible with tcp is it?
I have tried momentarily interrupting the connection BSC<->BTS with
iptables but I cannot as yet provoke the event that causes this.. ah
just now it happens again (meanwhile I am watching a straight ping to
the bts (for what it's worth) and I see nothing unusual there.
Maybe this actually has not got to do with the wifi link after all, and
that is just coincidence?

<0004> abis_rsl.c:717 (bts=0,trx=0,ts=1,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=1,ss=0) CHAN REL ACK for broken
channel. Releasing it.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=1) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=0) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=2) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=3) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=4) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:1464 (bts=1,trx=0,ts=1,ss=5) Activating ARFCN(251)
SS(5) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=3
<0004> abis_rsl.c:1464 (bts=1,trx=0,ts=1,ss=6) Activating ARFCN(251)
SS(6) lctype SDCCH r=LOCATION_UPDATE ra=0x0f ta=3
<0004> abis_rsl.c:1464 (bts=1,trx=0,ts=1,ss=7) Activating ARFCN(251)
SS(7) lctype SDCCH r=LOCATION_UPDATE ra=0x0a ta=3
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=0) Activating ARFCN(249)
SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0c ta=2
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=1) Activating ARFCN(249)
SS(1) lctype SDCCH r=OTHER ra=0x1c ta=1
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=2) Activating ARFCN(249)
SS(2) lctype SDCCH r=LOCATION_UPDATE ra=0x0d ta=2
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=3) Activating ARFCN(249)
SS(3) lctype SDCCH r=OTHER ra=0x10 ta=1
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=4) Activating ARFCN(249)
SS(4) lctype SDCCH r=LOCATION_UPDATE ra=0x07 ta=2
<0004> abis_rsl.c:1464 (bts=0,trx=0,ts=1,ss=5) Activating ARFCN(249)
SS(5) lctype SDCCH r=OTHER ra=0x17 ta=1
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=5) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=6) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=1,trx=0,ts=1,ss=7) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=0) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=1) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=2) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=3) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=4) Timeout during activation.
Marked as broken.
<0004> abis_rsl.c:211 (bts=0,trx=0,ts=1,ss=5) Timeout during activation.
Marked as broken.





From nhofmeyr at sysmocom.de  Thu Aug 18 02:06:14 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 18 Aug 2016 04:06:14 +0200
Subject: [openggsn] [PATCH 1/2] Fix possible buffer overflow for gsn_restart
 file path
Message-ID: <1471485975-1775-1-git-send-email-nhofmeyr@sysmocom.de>

For strncat, to obtain n, one must not subtract the length of what is appended,
but the length of what is already written from the buffer size.

Verified with this little test program:

 #include <stdio.h>
 #include <string.h>

 int main() {
   char buf[20];
   strncpy(buf, "123", 10);
   strncat(buf, "456789012345", 10 - strlen(buf));
   printf("%s\n", buf);
   return 0;
 }

It prints "1234567890".
---
 gtp/gtp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index 12cb492..34e1dc6 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -648,9 +648,10 @@ static void log_restart(struct gsn_t *gsn)
 	int counter = 0;
 	char filename[NAMESIZE];
 
-	filename[NAMESIZE - 1] = 0;	/* No null term. guarantee by strncpy */
+	/* guarantee nul term, strncpy might omit if too long */
+	filename[NAMESIZE - 1] = 0;
 	strncpy(filename, gsn->statedir, NAMESIZE - 1);
-	strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE));
+	strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
 
 	i = umask(022);
 
-- 
2.1.4



From nhofmeyr at sysmocom.de  Thu Aug 18 02:06:15 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 18 Aug 2016 04:06:15 +0200
Subject: [openggsn] [PATCH 2/2] add missing path separator for gsn_restart file
In-Reply-To: <1471485975-1775-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1471485975-1775-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1471485975-1775-2-git-send-email-nhofmeyr@sysmocom.de>

Put restart file in dir/gsn_restart instead of ../dirgsn_restart.
---
 gtp/gtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index 34e1dc6..702e502 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -651,7 +651,7 @@ static void log_restart(struct gsn_t *gsn)
 	/* guarantee nul term, strncpy might omit if too long */
 	filename[NAMESIZE - 1] = 0;
 	strncpy(filename, gsn->statedir, NAMESIZE - 1);
-	strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
+	strncat(filename, "/" RESTART_FILE, NAMESIZE - 1 - strlen(filename));
 
 	i = umask(022);
 
-- 
2.1.4



From holger at freyther.de  Thu Aug 18 06:38:13 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 18 Aug 2016 08:38:13 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <1f28fcbe-54c4-0137-cff2-ff171f535289@rhizomatica.org>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
 <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
 <782143EB-AF08-4549-9802-2E8690DBEE37@freyther.de>
 <1f28fcbe-54c4-0137-cff2-ff171f535289@rhizomatica.org>
Message-ID: <1F93FBDF-A569-4A11-B7CF-50B789B7E7CD@freyther.de>


> On 18 Aug 2016, at 00:28, Keith <keith at rhizomatica.org> wrote:
> 
> 

Good Morning Keith,

>> * List libosmocore/libosmo-abis/../OpenBSC/osmo-bts git commit (+patches if it makes sense)
> Unknown, as I didn't build it, but we could dispense with this, and I
> can just compile from a know good/recent commit and go from there.

well, dpkg -l and changelogs should give you an idea what rhizomatica has deployed. But without knowing which versions are in place, it is extremely difficult to look.

Same for the BTS and firmware version (opkg list_installed). E.g. it wouldn't make sense to chase issues in old firmware releases.




>> * Attach both BTS and NITB config

missing. Very crucial part of the puzzle. My assumptions right now:

* Do you use depends-on-bts to add dependency between BTS #1 and BTS #2 of the sysmoBTS 2050?




>> * PCAP file (if it doesn't include personal data, otherwise try to pseudomize it or share out of band).
>> 
> I think specifically a capture of the point at which this kind of thing
> starts to happen would be the interesting part, although I have to sit
> around for a while to get it. Not sure how to filter then the resulting
> pcap to just that part but I'll figure it out.

a good point will be to filter for "bts=0, trx=0, ts=1, ss=0" in RSL packages.


> <0004> abis_rsl.c:630 (bts=1,trx=0,ts=1,ss=0) is back in operation.
> <0004> abis_rsl.c:615 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD
> <0004> abis_rsl.c:1102 (bts=0,trx=0,ts=1,ss=0): MEAS RES for inactive
> channel
> <0004> abis_rsl.c:1330 (bts=0,trx=0,ts=1,ss=0) SACCH deactivation timeout.
> <0004> abis_rsl.c:661 (bts=0,trx=0,ts=1,ss=0) RF Channel Release CMD due
> error 1
> <0004> abis_rsl.c:1102 (bts=0,trx=0,ts=1,ss=0): MEAS RES for inactive
> channel
> <0004> abis_rsl.c:223 (bts=0,trx=0,ts=1,ss=0) Timeout during
> deactivation! Marked as broken.


So SACCH didn't detect signal, error handling, channel release and then no answer. If you enable timestamps in the printing we would see how much time has passed. But it must be at least four seconds.



> now, Just as soon as what I said in a previous mail about not having
> seen it, those rsl log entries are followed by
> 
> <0004> abis_rsl.c:717 (bts=0,trx=0,ts=1,ss=0) RF CHANNEL RELEASE ACK
> <0004> abis_rsl.c:735 (bts=0,trx=0,ts=1,ss=0) CHAN REL ACK for broken
> channel. Releasing it.

So here it "repaired it"


do_lchan_free()
	...
        } else {
                rsl_lchan_set_state(lchan, LCHAN_S_NONE);
        }
        lchan_free(lchan);




> However, this follows in the log and these remain broken "forever"
> 
> <0004> abis_rsl.c:1198 (bts=0,trx=0,ts=1,ss=1) CHANNEL ACTIVATE ACK
> <0004> abis_rsl.c:949 (bts=0,trx=0,ts=1,ss=1) CHAN ACT ACK for broken
> channel.

We are missing the activation. But only non-broken channels should be allocated. So it looks like the BTS(firmware) had enough? We can add the same "freeing" to the channel_act_ack as well. But you should have a look if:

* Delay is added by network
* Delay is added by BTS being too busy


holger


PS: With TCP it is not possible for something that has been written into the socket to arrive out-of-order. It might be that the BTS has not written into it (but that doesn't seem to be the case either).




From holger at freyther.de  Thu Aug 18 07:05:33 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 18 Aug 2016 09:05:33 +0200
Subject: lchan broken unusable activation timeout
In-Reply-To: <1F93FBDF-A569-4A11-B7CF-50B789B7E7CD@freyther.de>
References: <8e919bf3-1ff1-8fe3-b8be-3a9673e0ae4f@rhizomatica.org>
 <6BA19B17-6E57-4608-A67E-42998CF45E44@freyther.de>
 <54e455db-8355-84d6-2846-084378f575bb@rhizomatica.org>
 <2B59E197-AEBD-42A4-B7F8-E758EC6962A7@freyther.de>
 <87ef8590-a70f-2e14-74b5-afe21b9af47a@rhizomatica.org>
 <8D2E8CBA-A4FA-4DD1-860B-85F0E26E8EFE@freyther.de>
 <782143EB-AF08-4549-9802-2E8690DBEE37@freyther.de>
 <1f28fcbe-54c4-0137-cff2-ff171f535289@rhizomatica.org>
 <1F93FBDF-A569-4A11-B7CF-50B789B7E7CD@freyther.de>
Message-ID: <B2F6F112-6D6A-43F7-8E6C-859321FC2432@freyther.de>


> On 18 Aug 2016, at 08:38, Holger Freyther <holger at freyther.de> wrote:
> 
> We are missing the activation. But only non-broken channels should be allocated. So it looks like the BTS(firmware) had enough? We can add the same "freeing" to the channel_act_ack as well. But you should have a look if:

https://gerrit.osmocom.org/#/c/713/ for the untested activation fix-up. Do you have a gerrit log-in? For a ticket like this it would be nice to be able to put you as reviewer to make you aware of the change.

There are two patchsets, one before dynts was completed and one for latest master.

holger

From holger at freyther.de  Thu Aug 18 08:42:04 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 18 Aug 2016 10:42:04 +0200
Subject: [openggsn] [PATCH 1/2] Fix possible buffer overflow for
 gsn_restart file path
In-Reply-To: <1471485975-1775-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1471485975-1775-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <61D64E76-BA05-4D55-9C91-6B4D4308F84A@freyther.de>


> On 18 Aug 2016, at 04:06, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> For strncat, to obtain n, one must not subtract the length of what is appended,
> but the length of what is already written from the buffer size.
> 

let's use talloc_asprintf or the append variant of it. The place doesn't look like performance critical code.

holger



From sami.0jacob0 at gmail.com  Thu Aug 18 13:43:30 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 18 Aug 2016 16:43:30 +0300
Subject: Silent call
Message-ID: <6F718142-07E0-4B78-AC69-DA43600067AE@gmail.com>

Dear all,

Does the Silent-call feature provide the same features of testcall from openbts ? Is there a way to use the fuzzer code with it ?

Best regards,
Sami,

From sami.0jacob0 at gmail.com  Wed Aug 24 12:55:01 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Wed, 24 Aug 2016 15:55:01 +0300
Subject: openBSC OTA
Message-ID: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>

Hi,

Does openbsc support OTA messages? Is there any documentation about this subject ?



From laforge at gnumonks.org  Thu Aug 25 04:10:58 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Aug 2016 13:10:58 +0900
Subject: openBSC OTA
In-Reply-To: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
Message-ID: <20160825041058.w6mmrv6l32oosnsc@nataraja>

Hi Sami,

On Wed, Aug 24, 2016 at 03:55:01PM +0300, sami wrote:
> Does openbsc support OTA messages? Is there any documentation about this subject ?

In case you're referring to over-the-air SIM card related messages:
Those are either sent over SMS, Cell Broadcast or BIP.  BIP operates
over GPRS, so it is an application layer issue.

The least common denominator is typically SMS, and from the GSM network
(and OsmoNITB) point of view, they are just normal SMSs.  You can e.g.
submit them via SMPP from an external program.

So:
* yes you can use OpenBSC to transport OTA messages
* no, we don't implement them as they are outsie of the scope and
  implemented as part of an external SMS-sending/receiving program tat
  implements SMPP.

-- 
- 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 sami.0jacob0 at gmail.com  Thu Aug 25 07:41:03 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 25 Aug 2016 10:41:03 +0300
Subject: openBSC OTA
In-Reply-To: <20160825041058.w6mmrv6l32oosnsc@nataraja>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
Message-ID: <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>

Hi,

So if I understand it right, if I want to use SMS to send ota, I can either send it from an external program that implements SMPP or from another phone connected to openbsc (phone running an application that generates binary SMS).


Best regards,
Sami,

On Aug 25, 2016, at 7:10 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sami,
> 
> On Wed, Aug 24, 2016 at 03:55:01PM +0300, sami wrote:
>> Does openbsc support OTA messages? Is there any documentation about this subject ?
> 
> In case you're referring to over-the-air SIM card related messages:
> Those are either sent over SMS, Cell Broadcast or BIP.  BIP operates
> over GPRS, so it is an application layer issue.
> 
> The least common denominator is typically SMS, and from the GSM network
> (and OsmoNITB) point of view, they are just normal SMSs.  You can e.g.
> submit them via SMPP from an external program.
> 
> So:
> * yes you can use OpenBSC to transport OTA messages
> * no, we don't implement them as they are outsie of the scope and
>  implemented as part of an external SMS-sending/receiving program tat
>  implements SMPP.
> 
> -- 
> - 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 Aug 25 08:21:21 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Aug 2016 17:21:21 +0900
Subject: openBSC OTA
In-Reply-To: <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
Message-ID: <20160825082121.2jmjdvzpxtpax6ey@nataraja>

On Thu, Aug 25, 2016 at 10:41:03AM +0300, sami wrote:
> So if I understand it right, if I want to use SMS to send ota, I can
> either send it from an external program that implements SMPP or from
> another phone connected to openbsc (phone running an application that
> generates binary SMS).

correct.  Please see the OsmoNITB user manual chapter on SMPP
configuration, and the smpp_mirror example we included in openbsc.git
as a demo on how to use the SMPP interface from libsmpp34.  There's also
a python library for SMPP 3.4, as far as I remember.

-- 
- 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 sami.0jacob0 at gmail.com  Thu Aug 25 09:16:31 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 25 Aug 2016 12:16:31 +0300
Subject: openBSC OTA
In-Reply-To: <20160825082121.2jmjdvzpxtpax6ey@nataraja>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
Message-ID: <8E16C281-A89B-491A-8395-A35194E5BFC3@gmail.com>

I will check it. Thanks a lot !

Best regards,
Sami,

On Aug 25, 2016, at 11:21 AM, Harald Welte <laforge at gnumonks.org> wrote:

> On Thu, Aug 25, 2016 at 10:41:03AM +0300, sami wrote:
>> So if I understand it right, if I want to use SMS to send ota, I can
>> either send it from an external program that implements SMPP or from
>> another phone connected to openbsc (phone running an application that
>> generates binary SMS).
> 
> correct.  Please see the OsmoNITB user manual chapter on SMPP
> configuration, and the smpp_mirror example we included in openbsc.git
> as a demo on how to use the SMPP interface from libsmpp34.  There's also
> a python library for SMPP 3.4, as far as I remember.
> 
> -- 
> - 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 sami.0jacob0 at gmail.com  Thu Aug 25 11:07:48 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 25 Aug 2016 14:07:48 +0300
Subject: openBSC OTA
In-Reply-To: <20160825082121.2jmjdvzpxtpax6ey@nataraja>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
Message-ID: <4D3F4F46-FADE-46F3-84A5-172D8C28EBC5@gmail.com>

Hi,

I found the smpp_mirror.c script but didn?t find any example about using it. Is it through telnet ?
Also, in case I send ota messages to a certain phone, can I tell it to change some call related procedures, ex: auto-answer the incoming call, auto-reject certain numbers, do not ring ... 

Best regards,
Sami,

On Aug 25, 2016, at 11:21 AM, Harald Welte <laforge at gnumonks.org> wrote:

> On Thu, Aug 25, 2016 at 10:41:03AM +0300, sami wrote:
>> So if I understand it right, if I want to use SMS to send ota, I can
>> either send it from an external program that implements SMPP or from
>> another phone connected to openbsc (phone running an application that
>> generates binary SMS).
> 
> correct.  Please see the OsmoNITB user manual chapter on SMPP
> configuration, and the smpp_mirror example we included in openbsc.git
> as a demo on how to use the SMPP interface from libsmpp34.  There's also
> a python library for SMPP 3.4, as far as I remember.
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Thu Aug 25 12:40:30 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 25 Aug 2016 14:40:30 +0200
Subject: openBSC OTA
In-Reply-To: <4D3F4F46-FADE-46F3-84A5-172D8C28EBC5@gmail.com>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
 <4D3F4F46-FADE-46F3-84A5-172D8C28EBC5@gmail.com>
Message-ID: <F3FE4D2A-5153-4C0F-8E4C-05225B05E011@freyther.de>


> On 25 Aug 2016, at 13:07, sami <sami.0jacob0 at gmail.com> wrote:
> 
> Hi,
> 
> I found the smpp_mirror.c script but didn?t find any example about using it. Is it through telnet ?
> Also, in case I send ota messages to a certain phone, can I tell it to change some call related procedures, ex: auto-answer the incoming call, auto-reject certain numbers, do not ring ... 

SMPP:

use Net::SMPP;
$smpp = Net::SMPP->new_transceiver('127.0.0.1', port=>2775, system_id=>'anID', password=> 'pingpong', system_type=>'GSM') or die;

$smpp->submit_sm(
	service_type => '',
	source_addr => '123',
	protocol_id => 0x00,
	destination_addr => '2623213213',
	dest_addr_ton => 0x1,
	dest_addr_npi => 0x1,
	short_message => 'bla',
	);


This is a perl example, you will need to change ton/npi to be something !IMSI for your case.



Settings:

Well, I don't know your phone or such to know if such things can be changed.


holger

From sami.0jacob0 at gmail.com  Thu Aug 25 13:26:53 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 25 Aug 2016 16:26:53 +0300
Subject: openBSC OTA
In-Reply-To: <F3FE4D2A-5153-4C0F-8E4C-05225B05E011@freyther.de>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
 <4D3F4F46-FADE-46F3-84A5-172D8C28EBC5@gmail.com>
 <F3FE4D2A-5153-4C0F-8E4C-05225B05E011@freyther.de>
Message-ID: <81E21AE2-FE7D-423C-872E-89922A5B81DC@gmail.com>

Hi,

On Aug 25, 2016, at 3:40 PM, Holger Freyther <holger at freyther.de> wrote:

> 
>> On 25 Aug 2016, at 13:07, sami <sami.0jacob0 at gmail.com> wrote:
>> 
>> Hi,
>> 
>> I found the smpp_mirror.c script but didn?t find any example about using it. Is it through telnet ?
>> Also, in case I send ota messages to a certain phone, can I tell it to change some call related procedures, ex: auto-answer the incoming call, auto-reject certain numbers, do not ring ... 
> 
> SMPP:
> 
> use Net::SMPP;
> $smpp = Net::SMPP->new_transceiver('127.0.0.1', port=>2775, system_id=>'anID', password=> 'pingpong', system_type=>'GSM') or die;
> 
> $smpp->submit_sm(
> 	service_type => '',
> 	source_addr => '123',
> 	protocol_id => 0x00,
> 	destination_addr => '2623213213',
> 	dest_addr_ton => 0x1,
> 	dest_addr_npi => 0x1,
> 	short_message => 'bla',
> 	);
> 
> 
> This is a perl example, you will need to change ton/npi to be something !IMSI for your case.
> 
> 
> 
> Settings:
> 
> Well, I don't know your phone or such to know if such things can be changed.

So it depends on the phone model ? Is it at least doable for any model ? 
> 
> 
> holger



From holger at freyther.de  Fri Aug 26 07:19:06 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 26 Aug 2016 09:19:06 +0200
Subject: openBSC OTA
In-Reply-To: <81E21AE2-FE7D-423C-872E-89922A5B81DC@gmail.com>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
 <4D3F4F46-FADE-46F3-84A5-172D8C28EBC5@gmail.com>
 <F3FE4D2A-5153-4C0F-8E4C-05225B05E011@freyther.de>
 <81E21AE2-FE7D-423C-872E-89922A5B81DC@gmail.com>
Message-ID: <2BE0DECC-D2EC-4AE5-AB9F-E69CB6B03F4A@freyther.de>


> On 25 Aug 2016, at 15:26, sami <sami.0jacob0 at gmail.com> wrote:
> 
>> 
>> Well, I don't know your phone or such to know if such things can be changed.
> 
> So it depends on the phone model ? Is it at least doable for any model ? 


I have no idea. Tell us if you find something.

holger




From sami.0jacob0 at gmail.com  Fri Aug 26 08:39:38 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Fri, 26 Aug 2016 11:39:38 +0300
Subject: openBSC OTA
In-Reply-To: <20160825082121.2jmjdvzpxtpax6ey@nataraja>
References: <662977EA-1927-46D7-B136-A969EA124FDB@gmail.com>
 <20160825041058.w6mmrv6l32oosnsc@nataraja>
 <8F3FC81E-2AE4-488D-9C9D-F7212DEB4197@gmail.com>
 <20160825082121.2jmjdvzpxtpax6ey@nataraja>
Message-ID: <AD512EB3-DF29-404D-9D52-B1C062CC5D83@gmail.com>

Hi,

I have one final question. When the ota message is sent how can you make sure that the target phone has received it? Does it display anything ?

Best regards,
Sami,


On Aug 25, 2016, at 11:21 AM, Harald Welte <laforge at gnumonks.org> wrote:

> On Thu, Aug 25, 2016 at 10:41:03AM +0300, sami wrote:
>> So if I understand it right, if I want to use SMS to send ota, I can
>> either send it from an external program that implements SMPP or from
>> another phone connected to openbsc (phone running an application that
>> generates binary SMS).
> 
> correct.  Please see the OsmoNITB user manual chapter on SMPP
> configuration, and the smpp_mirror example we included in openbsc.git
> as a demo on how to use the SMPP interface from libsmpp34.  There's also
> a python library for SMPP 3.4, as far as I remember.
> 
> -- 
> - 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 Aug 29 09:41:52 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 29 Aug 2016 11:41:52 +0200
Subject: gerrit patch verification vs. rebase upon submission
Message-ID: <20160829094152.GB30254@dub7>

Hi all,

I've expected this before and now it has actually happened: a patch that was
verified by jenkins caused a build failure after being merged by gerrit.
Let's be aware of the possibility of this happening:

Commit [1] changed the rcv_rach() signature and correctly fixed all callers.
Commit [2] added a new caller of rcv_rach(), with the correct, old arguments.

Both tested successfully on their own, and were accepted for merge. [2] was
merged first, thus [1] no longer edited all callers as would have been
necessary.

One way to catch this: gerrit could run another jenkins build every time when
we hit the Submit button and 'master' has already moved on.  Not sure if this
is easily achievable.

The other way to catch this are the regular (non-gerrit) jenkins builds on
http://jenkins.osmocom.org/jenkins . Maybe selected jobs could send failure
reports to the noisy gerrit mailing list...

Another way we would see this is as soon as another patch is rebased onto
master, or when testing locally, obviously.

Thanks for your attention,

~Neels


[1] "Change interface in osmo-pcu for 11 bit RACH"
    959d1dee67e1c6fcfc57b347be2fb7a2ed099b2d

[2] "EGPRS: PUAN encoding: add test case to show wrong urbb_len issue" 
    02352b487ac6808b6adb8e8623f0921aad7f02d7

-- 
- 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/20160829/4b03e5f3/attachment.bin>

From holger at freyther.de  Mon Aug 29 10:17:10 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 29 Aug 2016 12:17:10 +0200
Subject: gerrit patch verification vs. rebase upon submission
In-Reply-To: <20160829094152.GB30254@dub7>
References: <20160829094152.GB30254@dub7>
Message-ID: <9AD9FFC4-1004-4B2F-B3FF-748C06D34641@freyther.de>


> On 29 Aug 2016, at 11:41, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> Hi all,

Hi!


> I've expected this before and now it has actually happened: a patch that was
> verified by jenkins caused a build failure after being merged by gerrit.
> Let's be aware of the possibility of this happening:
> 
> Commit [1] changed the rcv_rach() signature and correctly fixed all callers.
> Commit [2] added a new caller of rcv_rach(), with the correct, old arguments.
> 
> Both tested successfully on their own, and were accepted for merge. [2] was
> merged first, thus [1] no longer edited all callers as would have been
> necessary.

it happens. One option is to wait after the rebase. It should trigger a new build but is not too convenient.


holger

From alexander.huemer at xx.vu  Mon Aug 29 11:48:22 2016
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Mon, 29 Aug 2016 13:48:22 +0200
Subject: BS11 Outdoor casing
Message-ID: <20160829114822.GC3261@yade.xx.vu>

Hi,

I have a Siemens BS11 outdoor casing lying around, still in the original
box that is taking up space.
It is available free of charge, shipping costs have to paid though.
In case you are interested, contact me. First come, first serve.
It will otherwise be thrown away coming Friday.

Kind regards,
-Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160829/7902630c/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Aug 31 08:13:09 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 31 Aug 2016 10:13:09 +0200
Subject: Error compiling libosmocore under Mac Osx
In-Reply-To: <CAEE4hv2+U9L2AS_6UZr=CyL-R0J58miD2+GGOLsoacRRAhVZNg@mail.gmail.com>
References: <CAEE4hv0KYLiaCfHehZf8ht0ctTGZQTUO37e6x0x4VMRNgS3+Ww@mail.gmail.com>
 <20160713132606.GB1685@dub6>
 <CAEE4hv2+U9L2AS_6UZr=CyL-R0J58miD2+GGOLsoacRRAhVZNg@mail.gmail.com>
Message-ID: <20160831081309.GA1570@dub7>

On Wed, Jul 13, 2016 at 07:42:39PM +0200, Juan Antonio Barea Lopez wrote:
> Well, the commands i used were:
> ./configure --disable-pcsc (this is for not installing the chipcard library

Hi Juan,

today a patch for Mac OSX showed up that looks like it fixes exactly your
problem:
https://gerrit.osmocom.org/#/c/802/1/src/codec/Makefile.am

It will probably be merged to master soon, but until then you could fix up that
line in you Makefile.am manually.

~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/20160831/0426f0e6/attachment.bin>

From fanx07 at gmail.com  Wed Aug 31 08:29:57 2016
From: fanx07 at gmail.com (Anonim Stefan)
Date: Wed, 31 Aug 2016 11:29:57 +0300
Subject: osmo-sip-connector codecs
Message-ID: <CAO7wsJvQMGiDKHb2KkKcEoXtcEr3d6SrYNsBoMeBw3JC1bKo+g@mail.gmail.com>

Hi,

Is there a way to make osmo-sip-connector advertise additional codecs
(e.g.G711) besides GSM codec?

Thanks,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160831/9c5f31bb/attachment.htm>

From holger at freyther.de  Wed Aug 31 13:20:10 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 31 Aug 2016 15:20:10 +0200
Subject: osmo-sip-connector codecs
In-Reply-To: <CAO7wsJvQMGiDKHb2KkKcEoXtcEr3d6SrYNsBoMeBw3JC1bKo+g@mail.gmail.com>
References: <CAO7wsJvQMGiDKHb2KkKcEoXtcEr3d6SrYNsBoMeBw3JC1bKo+g@mail.gmail.com>
Message-ID: <6672C41B-C49A-40BD-86B5-78C1E73C8D03@freyther.de>


> On 31 Aug 2016, at 10:29, Anonim Stefan <fanx07 at gmail.com> wrote:
> 
> Hi,

Hey,


> Is there a way to make osmo-sip-connector advertise additional codecs (e.g.G711) besides GSM codec?

no transcoding will be done by the sip connector but if you switch to a AMR it should be able to advertize it.


holger