From laforge at gnumonks.org  Thu Feb  1 00:13:15 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 1 Feb 2018 01:13:15 +0100
Subject: On the use of 'decmatch' in TTCN-3
In-Reply-To: <d2ec74ba-c32b-aaf6-836f-d207c3ad57a3@sysmocom.de>
References: <20180131223834.GJ20115@nataraja>
 <d2ec74ba-c32b-aaf6-836f-d207c3ad57a3@sysmocom.de>
Message-ID: <20180201001315.GM20115@nataraja>

Hi Pau,

On Thu, Feb 01, 2018 at 12:18:11AM +0100, Pau Espin Pedrol wrote:

> thanks for the explanation! However, it's still not clear to me how to get
> the decoded payload out of the receive statement. From
> https://www.eclipse.org/forums/index.php/t/1089269/ I saw there's this
> "@decoded" keyword you can use but I couldn't figure out how to really use
> it in a proper way, and what exactly I would be getting with it.

The ETSI TTCN-3 language spec actually has plenty of useful examples.

>From ETSI ES 201 873-1 V4.8.1, Section 22.2.2 Example 2:

MyPort.receive(MyType2:{header := ?, payload := decmatch mw_myTemplate}) -> value (v_myVar := @decoded payload);
// The encoded payload field of the received message is decoded and matched with
// mw_myTemplate; if the matching is successful the decoded payload is stored in v_myVar.

> I'm also wondering if several decmatch expressions can be stacked in a
> single statment, for instance image something like:

I have no idea, guess you'd have to try.

> RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS(foo,
> bar, decmatch tr_ANOTHER_TEMPLATE)).
> Linking it with first question, what I would be getting when using the
> @decoded keyword in this case?

I guess you should raise that in the Eclipse Titan forum ;)

> And extra question I asked myself while doing some tests today: is there a
> way to check if a template received through a function parameter matches a
> specific template? 

templates cannot match other templates.  They can only match values 

> I tried with match() but from what I understood from the
> compilation errors, it seems match() actually checks a value vs a template,

correct.

> Hm maybe just using "==" would work, I didn't check it.

You can compare if two templates are equal.  I would argue that this is not the
same as your question "a template matches a template".  So using "==" between
two identical templates should evaluate true (I don't think I ever tried).  But
for sure, a more generic template wound not be equal to a more specific template,
even though there are values that could match both templates.

> Last query: Did you find a good tutorial or well documented examples for
> beginners in some specific place?

I've so far been looking primarily at
* https://www.ttcn-3.org/files/TTCN3_P.pdf
* the above-mentioned ETSI core language spec for TTCN-3
* the Eclipse/Ericsson TITAN referenceguide.pdf "Programmers Guide"
  which is part of https://www.eclipse.org/downloads/download.php?file=/titan/TitanDocuments_6_3_0.zip

-- 
- 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 djks74 at gmail.com  Thu Feb  1 19:14:41 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Thu, 1 Feb 2018 19:14:41 +0000
Subject: strange registering behaviour on osmo-bsc
Message-ID: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>

Dear list,
I test again with new build for osmo-bsc osmo-msc-osmo-hlr

I dont know if the osmo-hlr and osmo-bsc has been fixing or I have mistake
for configuration which I did not change from the success I test before,
but now I cannot register my phone and even make the network error and keep
on emergency only when registering on the phone.

at osmo-hlr I got this :

20180201190135844 DAUC <0003> hlr.c:79 510106127044410: IMSI known, but has
no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via GSUP

Does the new osmo-bsc on master cannot use? or maybe I need to investigate
more?

Thanks for any feedback!

-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180201/5c235ffd/attachment.htm>

From laforge at gnumonks.org  Fri Feb  2 07:13:19 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 2 Feb 2018 08:13:19 +0100
Subject: strange registering behaviour on osmo-bsc
In-Reply-To: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>
References: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>
Message-ID: <20180202071319.GR10874@nataraja>

Hi!

On Thu, Feb 01, 2018 at 07:14:41PM +0000, Sandi Suhendro wrote:
> 20180201190135844 DAUC <0003> hlr.c:79 510106127044410: IMSI known, but has
> no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via GSUP

the error is quite clear: You have only an IMSI in your HLR, but no authentication
tokens (key material) for cryptographic authentication.

If at the same time you have configured your network to perform authentication (i.e.
not explicitly disabled it), then this will of course result in an error.

Either you enter key data in the HLR for your SIM cards, or you disable authentication.

> Does the new osmo-bsc on master cannot use? or maybe I need to investigate
> more?

The BSC has nothing to do with it.  Your error is in OsmoMSC or OsmoHLR configuration.

-- 
- 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 djks74 at gmail.com  Fri Feb  2 11:30:02 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Fri, 2 Feb 2018 11:30:02 +0000
Subject: strange registering behaviour on osmo-bsc
In-Reply-To: <20180202071319.GR10874@nataraja>
References: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>
 <20180202071319.GR10874@nataraja>
Message-ID: <CANWiJYjqJeLTMo+Vv9ORrEZ5mdpSe9gTwUSNaVqXhxvfOKj3NA@mail.gmail.com>

Dear Harald,
thank you for explanation, I really appreciate it.

So, osmo-hlr now need authentication for connect to the network? so we
cannot attach IMSI without the ki?

if Im not wrong I need to set disable it on the configuration?
 location updating reject cause 13
 encryption a5 1
 authentication optional

on this authentication line need to change? I try do change to
authentication disable, but not work. I believe I have wrong understanding
here.

Im using for 2g network. as far I know only for 3g network you need ki
right?

Hope some feedback. Thank you.

regards,
DUO

On Fri, Feb 2, 2018 at 7:13 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi!
>
> On Thu, Feb 01, 2018 at 07:14:41PM +0000, Sandi Suhendro wrote:
> > 20180201190135844 DAUC <0003> hlr.c:79 510106127044410: IMSI known, but
> has
> > no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via GSUP
>
> the error is quite clear: You have only an IMSI in your HLR, but no
> authentication
> tokens (key material) for cryptographic authentication.
>
> If at the same time you have configured your network to perform
> authentication (i.e.
> not explicitly disabled it), then this will of course result in an error.
>
> Either you enter key data in the HLR for your SIM cards, or you disable
> authentication.
>
> > Does the new osmo-bsc on master cannot use? or maybe I need to
> investigate
> > more?
>
> The BSC has nothing to do with it.  Your error is in OsmoMSC or OsmoHLR
> configuration.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>



-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180202/55f5ce54/attachment.htm>

From djks74 at gmail.com  Fri Feb  2 11:58:04 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Fri, 2 Feb 2018 11:58:04 +0000
Subject: strange registering behaviour on osmo-bsc
In-Reply-To: <CANWiJYjqJeLTMo+Vv9ORrEZ5mdpSe9gTwUSNaVqXhxvfOKj3NA@mail.gmail.com>
References: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>
 <20180202071319.GR10874@nataraja>
 <CANWiJYjqJeLTMo+Vv9ORrEZ5mdpSe9gTwUSNaVqXhxvfOKj3NA@mail.gmail.com>
Message-ID: <CANWiJYgAMNZ3aHHKNWwrU-ibW+6r-2CkgUXEKmnhYv168gJh4g@mail.gmail.com>

Dear Harald,
sorry for the authentication matter,
I got the solution now, I need to set encryption to a5 0 on the config.

Thanks for lightneing up before.

btw,
I try to make call but cannot hear the voices. will try this again and
again.

Thanks,
DUO

On Fri, Feb 2, 2018 at 11:30 AM, Sandi Suhendro <djks74 at gmail.com> wrote:

> Dear Harald,
> thank you for explanation, I really appreciate it.
>
> So, osmo-hlr now need authentication for connect to the network? so we
> cannot attach IMSI without the ki?
>
> if Im not wrong I need to set disable it on the configuration?
>  location updating reject cause 13
>  encryption a5 1
>  authentication optional
>
> on this authentication line need to change? I try do change to
> authentication disable, but not work. I believe I have wrong understanding
> here.
>
> Im using for 2g network. as far I know only for 3g network you need ki
> right?
>
> Hope some feedback. Thank you.
>
> regards,
> DUO
>
> On Fri, Feb 2, 2018 at 7:13 AM, Harald Welte <laforge at gnumonks.org> wrote:
>
>> Hi!
>>
>> On Thu, Feb 01, 2018 at 07:14:41PM +0000, Sandi Suhendro wrote:
>> > 20180201190135844 DAUC <0003> hlr.c:79 510106127044410: IMSI known, but
>> has
>> > no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via
>> GSUP
>>
>> the error is quite clear: You have only an IMSI in your HLR, but no
>> authentication
>> tokens (key material) for cryptographic authentication.
>>
>> If at the same time you have configured your network to perform
>> authentication (i.e.
>> not explicitly disabled it), then this will of course result in an error.
>>
>> Either you enter key data in the HLR for your SIM cards, or you disable
>> authentication.
>>
>> > Does the new osmo-bsc on master cannot use? or maybe I need to
>> investigate
>> > more?
>>
>> The BSC has nothing to do with it.  Your error is in OsmoMSC or OsmoHLR
>> configuration.
>>
>> --
>> - Harald Welte <laforge at gnumonks.org>
>> http://laforge.gnumonks.org/
>> ============================================================
>> ================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                   (ETSI EN 300 175-7 Ch.
>> A6)
>>
>
>
>
> --
> Best Regards,
> DUO
>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180202/9a73d90b/attachment.htm>

From djks74 at gmail.com  Fri Feb  2 12:54:44 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Fri, 2 Feb 2018 12:54:44 +0000
Subject: strange registering behaviour on osmo-bsc
In-Reply-To: <CANWiJYgAMNZ3aHHKNWwrU-ibW+6r-2CkgUXEKmnhYv168gJh4g@mail.gmail.com>
References: <CANWiJYhge=hfshR_-hr5Wrxuquy+uzjuAmDKzFQZOppi4g7gmg@mail.gmail.com>
 <20180202071319.GR10874@nataraja>
 <CANWiJYjqJeLTMo+Vv9ORrEZ5mdpSe9gTwUSNaVqXhxvfOKj3NA@mail.gmail.com>
 <CANWiJYgAMNZ3aHHKNWwrU-ibW+6r-2CkgUXEKmnhYv168gJh4g@mail.gmail.com>
Message-ID: <CANWiJYj7oXNtuag_dag-ZwEX6SjDgUVez1iiq-hg-PZEkUPz8Q@mail.gmail.com>

Dear Harald,
just wanna give report what I tests.
I test calls and when I picked up always hang up and paging fail for the
first call.

sometimes osmo-mgw having this fail:
0180202124344842 DLMGCP <0011> mgcp_msg.c:262 Addressing virtual trunk
without prefix (deprecated), please use rtpbridge/: '1 at mgw'
20180202124344842 DLMGCP <0011> mgcp_protocol.c:727 MDCX: modifying
existing connection ...
20180202124344842 DLMGCP <0011> mgcp_protocol.c:779 MDCX: endpoint:0x1
insufficient parameters, missing ci (connectionIdentifier)
20180202124344842 DLMGCP <0011> mgcp_protocol.c:154 Generated response:
code=515
20180202124344842 DLMGCP <0011> mgcp_msg.c:64 Generated response: line #00:
515 119 FAIL

but I think my configuration for osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg
has wrong cause I found this:
20180202115457644 DRTP <0000> mgcp_network.c:833 endpoint:0x1 data from
wrong address: 127.0.0.1, expected: 0.0.0.0
20180202115457644 DRTP <0000> mgcp_network.c:837 endpoint:0x1 packet tossed
20180202115457663 DRTP <0000> mgcp_network.c:1070 endpoint:0x1 source
conn:(1/rtp, id:0x9BD31876C21AF4272B337F95C5

I will try to look what may cause the connection hang up for my problem.

Thanks,
DUO




On Fri, Feb 2, 2018 at 11:58 AM, Sandi Suhendro <djks74 at gmail.com> wrote:

> Dear Harald,
> sorry for the authentication matter,
> I got the solution now, I need to set encryption to a5 0 on the config.
>
> Thanks for lightneing up before.
>
> btw,
> I try to make call but cannot hear the voices. will try this again and
> again.
>
> Thanks,
> DUO
>
> On Fri, Feb 2, 2018 at 11:30 AM, Sandi Suhendro <djks74 at gmail.com> wrote:
>
>> Dear Harald,
>> thank you for explanation, I really appreciate it.
>>
>> So, osmo-hlr now need authentication for connect to the network? so we
>> cannot attach IMSI without the ki?
>>
>> if Im not wrong I need to set disable it on the configuration?
>>  location updating reject cause 13
>>  encryption a5 1
>>  authentication optional
>>
>> on this authentication line need to change? I try do change to
>> authentication disable, but not work. I believe I have wrong understanding
>> here.
>>
>> Im using for 2g network. as far I know only for 3g network you need ki
>> right?
>>
>> Hope some feedback. Thank you.
>>
>> regards,
>> DUO
>>
>> On Fri, Feb 2, 2018 at 7:13 AM, Harald Welte <laforge at gnumonks.org>
>> wrote:
>>
>>> Hi!
>>>
>>> On Thu, Feb 01, 2018 at 07:14:41PM +0000, Sandi Suhendro wrote:
>>> > 20180201190135844 DAUC <0003> hlr.c:79 510106127044410: IMSI known,
>>> but has
>>> > no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via
>>> GSUP
>>>
>>> the error is quite clear: You have only an IMSI in your HLR, but no
>>> authentication
>>> tokens (key material) for cryptographic authentication.
>>>
>>> If at the same time you have configured your network to perform
>>> authentication (i.e.
>>> not explicitly disabled it), then this will of course result in an error.
>>>
>>> Either you enter key data in the HLR for your SIM cards, or you disable
>>> authentication.
>>>
>>> > Does the new osmo-bsc on master cannot use? or maybe I need to
>>> investigate
>>> > more?
>>>
>>> The BSC has nothing to do with it.  Your error is in OsmoMSC or OsmoHLR
>>> configuration.
>>>
>>> --
>>> - Harald Welte <laforge at gnumonks.org>
>>> http://laforge.gnumonks.org/
>>> ============================================================
>>> ================
>>> "Privacy in residential applications is a desirable marketing option."
>>>                                                   (ETSI EN 300 175-7 Ch.
>>> A6)
>>>
>>
>>
>>
>> --
>> Best Regards,
>> DUO
>>
>>
>
>
> --
> Best Regards,
> DUO
>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180202/1665783e/attachment.htm>

From holger at freyther.de  Sun Feb  4 22:35:04 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 4 Feb 2018 22:35:04 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
Message-ID: <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>



> On 29. Jan 2018, at 21:52, Holger Freyther <holger at freyther.de> wrote:
> 

Hey,

I wish I had better news. Instead of an end to end test I realize that picking "asyncio" was a grave mistake. Besides the lack AF_UNIX SOCK_DGRAM support, the process support is dangerous and doesn't scale. Today I stumbled into SIGCHLD handling of spawned processes. While normally neither virthphy/mobile would prematurely exit, a few exits could take the entire test down.

Speculating from the behavior of strace:

* SIGCHLD arrives
* Something will be written into one end of a socketpair[1]
* In the python code on wait(2) will be called on every registered process
(https://github.com/python/cpython/blob/3.6/Lib/asyncio/unix_events.py#L819)

As more processes exit the main python code is still in the for loop and the buffer runs full. It also means that the main application will be busy executing Xk syscalls instead of launching processes or events.


It is unfortunate that I only notice now but probably still better than having to deal mysterious failures of processes not starting and all tests failing. As not many people here know Go. I think I will stay with python but use the lower level epoll API directly. So we end up with a single "select" system... I should finally have something during the week.

I hope all of you had a nice fosdem!

holger


[1] A common trick to notify one thread or part of the application of an event. There is not much that is allowed in a signal handler so using a buffer is a reasonable approach.. It should forward the PID of the process that exited though.

From djks74 at gmail.com  Mon Feb  5 13:27:36 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 5 Feb 2018 20:27:36 +0700
Subject: Call not go through via osmocomBB/limesdr using osmo-bsc
Message-ID: <CANWiJYhx0+S+wXj+4oyH20F3cqxym=ZdXRaGSwS2rrbLAN3GDA@mail.gmail.com>

Dear list,
Hope some one can look my configuration since I cannot hear voices when
make calls outside network via asterisk, but cannot make calls between
phone on the same network.

please advise this config using osmocomBB.

here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-bsc.cfg
https://pastebin.com/NmQQ5hM6
the log :
https://pastebin.com/sNy2DxW9

here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-msc.cfg
https://pastebin.com/TCAq3YkL
the log :
https://pastebin.com/pEbe74BF

osmo-msc config :
https://pastebin.com/GS2YvjPf
the log :
https://pastebin.com/Ag52HaED

osmo-bsc config:
https://pastebin.com/nKQ0czW7

osmo-bts config:
https://pastebin.com/s5FamjMv

osmo-hlr config :
https://pastebin.com/RLgVEURS
the log :
https://pastebin.com/cAPf1DNs

osmo-stp
https://pastebin.com/anB0hsc5

hope someone can help to look and give advise really appreciate.

Thanks in advance.

-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180205/c83bfcc8/attachment.htm>

From laforge at gnumonks.org  Mon Feb  5 13:29:43 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 5 Feb 2018 14:29:43 +0100
Subject: RFC: making libosmo-mgcp a non-installed static library
Message-ID: <20180205132943.GG10874@nataraja>

Hi all,

I recently proposed the patch https://gerrit.osmocom.org/#/c/6270/
and I would like to get some input from a wider audience.

Basically, it turns libosmo-mgcp (the mgw/server side MGCP lib) into an
internal library similar to 'libmsc' in osmo-msc, which we don't expect
to be used by other programs except osmo-mgw.  Hence, there's no need to
install it as a shared library, which introduces requirements about
ABI/API stability and the like.

osmo-bsc_nat uses libosmo-legacy-mgcp, and once we should rewrite
osmo-bsc_nat, we might need some of the libosmo-mgcp related functions,
but at this point it's unclear what exactly would be needed and if
current libosmo-mgcp can provide that.  As needed, we can introduce
a related shared library at that point.

Do you guys agree with this move, or do you think there is a point in
having a public shared library with preferably stable API for the MGW
side of MGCP?  I think it just constrains us as to what we can do in
terms of code changes within the MGW - for no clear benefit.

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 pespin at sysmocom.de  Mon Feb  5 13:42:29 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 5 Feb 2018 14:42:29 +0100
Subject: RFC: making libosmo-mgcp a non-installed static library
In-Reply-To: <20180205132943.GG10874@nataraja>
References: <20180205132943.GG10874@nataraja>
Message-ID: <7fb90f66-041f-217d-b0a4-e54f7814860e@sysmocom.de>

Hi,

I think it makes sense to keep it internal until someone requires having 
it as a separated shared object to be used for more than one binary. We 
can always move it to a shared object but might be difficult doing the 
opposite move in the future, and as you say we then require keeping the 
API stable.


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


From djks74 at gmail.com  Tue Feb  6 05:28:08 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 6 Feb 2018 05:28:08 +0000
Subject: Call not go through via osmocomBB/limesdr using osmo-bsc
In-Reply-To: <CANWiJYhx0+S+wXj+4oyH20F3cqxym=ZdXRaGSwS2rrbLAN3GDA@mail.gmail.com>
References: <CANWiJYhx0+S+wXj+4oyH20F3cqxym=ZdXRaGSwS2rrbLAN3GDA@mail.gmail.com>
Message-ID: <CANWiJYghfDyQt3S2zThfUSwq1he2XOv9qXz39pX8Na5JesB9SQ@mail.gmail.com>

HI list,
Now, I can make calls with limeSDR but still cannot hear voices on both
phone.

here is the config and log, please have a look to help me wha is missing.

osmo-bsc log:
https://paste.ee/p/EASHy
config:
https://paste.ee/p/q8poG

osmo-bts-trx log:
https://paste.ee/p/987mK
config:
https://paste.ee/p/N533G

osmo-msc log:
https://paste.ee/p/MZGkw
config:
https://paste.ee/p/acMes

osmo-hlr log :
https://paste.ee/p/wFB7F
config
https://paste.ee/p/vwM8j

osmo-stp log
https://paste.ee/p/1MhkW
config
https://paste.ee/p/mXtlF

osmo-mgw-msc log
https://paste.ee/p/Y64yS
config
https://paste.ee/p/MHNtU

osmo-mgw-bsc log
https://paste.ee/p/YZhxA
config
https://paste.ee/p/x0a55

I believe I miss something in the configuration.

I really appreciate any help! Thanks.

regards,
DUO








On Mon, Feb 5, 2018 at 1:27 PM, Sandi Suhendro <djks74 at gmail.com> wrote:

> Dear list,
> Hope some one can look my configuration since I cannot hear voices when
> make calls outside network via asterisk, but cannot make calls between
> phone on the same network.
>
> please advise this config using osmocomBB.
>
> here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-bsc.cfg
> https://pastebin.com/NmQQ5hM6
> the log :
> https://pastebin.com/sNy2DxW9
>
> here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-msc.cfg
> https://pastebin.com/TCAq3YkL
> the log :
> https://pastebin.com/pEbe74BF
>
> osmo-msc config :
> https://pastebin.com/GS2YvjPf
> the log :
> https://pastebin.com/Ag52HaED
>
> osmo-bsc config:
> https://pastebin.com/nKQ0czW7
>
> osmo-bts config:
> https://pastebin.com/s5FamjMv
>
> osmo-hlr config :
> https://pastebin.com/RLgVEURS
> the log :
> https://pastebin.com/cAPf1DNs
>
> osmo-stp
> https://pastebin.com/anB0hsc5
>
> hope someone can help to look and give advise really appreciate.
>
> Thanks in advance.
>
> --
> Best Regards,
> DUO
>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180206/6c5e8fbc/attachment.htm>

From holger at freyther.de  Wed Feb  7 09:31:16 2018
From: holger at freyther.de (Holger Freyther)
Date: Wed, 7 Feb 2018 09:31:16 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
 <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
Message-ID: <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>



> On 4. Feb 2018, at 22:35, Holger Freyther <holger at freyther.de> wrote:

Hi,


> * SIGCHLD arrives
> * Something will be written into one end of a socketpair[1]
> * In the python code on wait(2) will be called on every registered process
> (https://github.com/python/cpython/blob/3.6/Lib/asyncio/unix_events.py#L819)


there is a way to switch to a child reaper that is using wait(-1.. but even
then we have two issues.

1.) If I use await asyncio.create_subprocess_exec... then we can't tick
with 50ms. On a 60s schedule to start 10k processes there is a delay of +60s.

2.) If I delay the process creation then I can almost keep the schedule most
of the time but we run into buffering exceptions and/or not all tasks are
started within a reasonable amount of time.

Knowing what I know now I would have gone for Go. It is made for the kind of
concurrency where python seems unusable. I hesitated to build my own event
loop but will build something that looks like our C apps in python (single
select, no async/await).

holger

From rafael at riseup.net  Wed Feb  7 12:47:08 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Wed, 7 Feb 2018 10:47:08 -0200
Subject: Call not go through via osmocomBB/limesdr using osmo-bsc
In-Reply-To: <CANWiJYghfDyQt3S2zThfUSwq1he2XOv9qXz39pX8Na5JesB9SQ@mail.gmail.com>
References: <CANWiJYhx0+S+wXj+4oyH20F3cqxym=ZdXRaGSwS2rrbLAN3GDA@mail.gmail.com>
 <CANWiJYghfDyQt3S2zThfUSwq1he2XOv9qXz39pX8Na5JesB9SQ@mail.gmail.com>
Message-ID: <db0ab17a-1131-d1b3-a91d-b02d0af156ff@riseup.net>

Hi Sandi,
I don't have audio with the new stack here too. I'm using a USRP.

Regards,
Rafael Diniz

On 02/06/2018 03:28 AM, Sandi Suhendro wrote:
> HI list,
> Now, I can make calls with limeSDR but still cannot hear voices on both
> phone.
> 
> here is the config and log, please have a look to help me wha is missing.
> 
> osmo-bsc log:
> https://paste.ee/p/EASHy
> config:
> https://paste.ee/p/q8poG
> 
> osmo-bts-trx log:
> https://paste.ee/p/987mK
> config:
> https://paste.ee/p/N533G
> 
> osmo-msc log:
> https://paste.ee/p/MZGkw
> config:
> https://paste.ee/p/acMes
> 
> osmo-hlr log :
> https://paste.ee/p/wFB7F
> config
> https://paste.ee/p/vwM8j
> 
> osmo-stp log
> https://paste.ee/p/1MhkW
> config
> https://paste.ee/p/mXtlF
> 
> osmo-mgw-msc log
> https://paste.ee/p/Y64yS
> config
> https://paste.ee/p/MHNtU
> 
> osmo-mgw-bsc log
> https://paste.ee/p/YZhxA
> config
> https://paste.ee/p/x0a55
> 
> I believe I miss something in the configuration.
> 
> I really appreciate any help! Thanks.
> 
> regards,
> DUO
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Feb 5, 2018 at 1:27 PM, Sandi Suhendro <djks74 at gmail.com
> <mailto:djks74 at gmail.com>> wrote:
> 
>     Dear list,
>     Hope some one can look my configuration since I cannot hear voices
>     when make calls outside network via asterisk, but cannot make calls
>     between phone on the same network.
> 
>     please advise this config using osmocomBB.
> 
>     here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-bsc.cfg
>     https://pastebin.com/NmQQ5hM6
>     the log :
>     https://pastebin.com/sNy2DxW9
> 
>     here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-msc.cfg
>     https://pastebin.com/TCAq3YkL
>     the log :
>     https://pastebin.com/pEbe74BF
> 
>     osmo-msc config :
>     https://pastebin.com/GS2YvjPf
>     the log :
>     https://pastebin.com/Ag52HaED
> 
>     osmo-bsc config:
>     https://pastebin.com/nKQ0czW7
> 
>     osmo-bts config:
>     https://pastebin.com/s5FamjMv
> 
>     osmo-hlr config :
>     https://pastebin.com/RLgVEURS
>     the log :
>     https://pastebin.com/cAPf1DNs
> 
>     osmo-stp
>     https://pastebin.com/anB0hsc5
> 
>     hope someone can help to look and give advise really appreciate.
> 
>     Thanks in advance.
> 
>     -- 
>     Best Regards,
>     DUO
> 
> 
> 
> 
> -- 
> Best Regards,
> DUO
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180207/d5c1bc72/attachment.bin>

From djks74 at gmail.com  Wed Feb  7 15:20:13 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 7 Feb 2018 22:20:13 +0700
Subject: Call not go through via osmocomBB/limesdr using osmo-bsc
In-Reply-To: <db0ab17a-1131-d1b3-a91d-b02d0af156ff@riseup.net>
References: <CANWiJYhx0+S+wXj+4oyH20F3cqxym=ZdXRaGSwS2rrbLAN3GDA@mail.gmail.com>
 <CANWiJYghfDyQt3S2zThfUSwq1he2XOv9qXz39pX8Na5JesB9SQ@mail.gmail.com>
 <db0ab17a-1131-d1b3-a91d-b02d0af156ff@riseup.net>
Message-ID: <CANWiJYim-6fQcqat2WVhvnrrTZcb+Su50rVpGbhon3yLsi9gMQ@mail.gmail.com>

Hi Rafael,
good to know!  so its not only me. :-)

how about others?

Thanks.

On Wed, Feb 7, 2018 at 7:47 PM, Rafael Diniz <rafael at riseup.net> wrote:

> Hi Sandi,
> I don't have audio with the new stack here too. I'm using a USRP.
>
> Regards,
> Rafael Diniz
>
> On 02/06/2018 03:28 AM, Sandi Suhendro wrote:
> > HI list,
> > Now, I can make calls with limeSDR but still cannot hear voices on both
> > phone.
> >
> > here is the config and log, please have a look to help me wha is missing.
> >
> > osmo-bsc log:
> > https://paste.ee/p/EASHy
> > config:
> > https://paste.ee/p/q8poG
> >
> > osmo-bts-trx log:
> > https://paste.ee/p/987mK
> > config:
> > https://paste.ee/p/N533G
> >
> > osmo-msc log:
> > https://paste.ee/p/MZGkw
> > config:
> > https://paste.ee/p/acMes
> >
> > osmo-hlr log :
> > https://paste.ee/p/wFB7F
> > config
> > https://paste.ee/p/vwM8j
> >
> > osmo-stp log
> > https://paste.ee/p/1MhkW
> > config
> > https://paste.ee/p/mXtlF
> >
> > osmo-mgw-msc log
> > https://paste.ee/p/Y64yS
> > config
> > https://paste.ee/p/MHNtU
> >
> > osmo-mgw-bsc log
> > https://paste.ee/p/YZhxA
> > config
> > https://paste.ee/p/x0a55
> >
> > I believe I miss something in the configuration.
> >
> > I really appreciate any help! Thanks.
> >
> > regards,
> > DUO
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Feb 5, 2018 at 1:27 PM, Sandi Suhendro <djks74 at gmail.com
> > <mailto:djks74 at gmail.com>> wrote:
> >
> >     Dear list,
> >     Hope some one can look my configuration since I cannot hear voices
> >     when make calls outside network via asterisk, but cannot make calls
> >     between phone on the same network.
> >
> >     please advise this config using osmocomBB.
> >
> >     here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-bsc.cfg
> >     https://pastebin.com/NmQQ5hM6
> >     the log :
> >     https://pastebin.com/sNy2DxW9
> >
> >     here is the osmo-mgw -c ~/osmobsc/osmo-mgw-for-msc.cfg
> >     https://pastebin.com/TCAq3YkL
> >     the log :
> >     https://pastebin.com/pEbe74BF
> >
> >     osmo-msc config :
> >     https://pastebin.com/GS2YvjPf
> >     the log :
> >     https://pastebin.com/Ag52HaED
> >
> >     osmo-bsc config:
> >     https://pastebin.com/nKQ0czW7
> >
> >     osmo-bts config:
> >     https://pastebin.com/s5FamjMv
> >
> >     osmo-hlr config :
> >     https://pastebin.com/RLgVEURS
> >     the log :
> >     https://pastebin.com/cAPf1DNs
> >
> >     osmo-stp
> >     https://pastebin.com/anB0hsc5
> >
> >     hope someone can help to look and give advise really appreciate.
> >
> >     Thanks in advance.
> >
> >     --
> >     Best Regards,
> >     DUO
> >
> >
> >
> >
> > --
> > Best Regards,
> > DUO
> >
>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180207/2e91a08a/attachment.htm>

From jenkins at lists.osmocom.org  Fri Feb  9 02:30:27 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Fri, 9 Feb 2018 02:30:27 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #6
Message-ID: <1091562705.73.1518143427767.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/6/display/redirect>

------------------------------------------
[...truncated 819.23 KB...]
  CXX      gprs_rlcmac.lo
  CXX      gprs_bssgp_pcu.lo
  CXX      gprs_rlcmac_sched.lo
  CXX      gprs_rlcmac_meas.lo
  CXX      gprs_rlcmac_ts_alloc.lo
  CXX      gprs_ms.lo
gprs_bssgp_pcu.cpp:967:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp]
 #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless"
  ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac_meas.lo' failed
make[1]: *** [gprs_rlcmac_meas.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:775: recipe for target 'gprs_rlcmac_ts_alloc.lo' failed
make[1]: *** [gprs_rlcmac_ts_alloc.lo] Error 1
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac_sched.lo' failed
make[1]: *** [gprs_rlcmac_sched.lo] Error 1
gprs_bssgp_pcu.cpp: At global scope:
gprs_bssgp_pcu.cpp:76:12: warning: ?int parse_ra_cap(tlv_parsed*, MS_Radio_Access_capability_t*)? defined but not used [-Wunused-function]
 static int parse_ra_cap(struct tlv_parsed *tp, MS_Radio_Access_capability_t *rac)
            ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_bssgp_pcu.lo' failed
make[1]: *** [gprs_bssgp_pcu.lo] Error 1
Makefile:775: recipe for target 'gprs_rlcmac.lo' failed
make[1]: *** [gprs_rlcmac.lo] Error 1
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from pcu_l1_if.h:27,
                 from gprs_ms.h:28,
                 from gprs_ms.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from gprs_coding_scheme.h:27:0,
                 from rlc.h:22,
                 from tbf.h:25,
                 from gprs_ms.h:27,
                 from gprs_ms.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from pcu_l1_if.h:27,
                 from gprs_ms.h:28,
                 from gprs_ms.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from gprs_coding_scheme.h:27:0,
                 from rlc.h:22,
                 from tbf.h:25,
                 from gprs_ms.h:27,
                 from gprs_ms.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_ms.lo' failed
make[1]: *** [gprs_ms.lo] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src'
Makefile:461: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 1854 C/C++ compilation units (100%) successfully
[WARNING] Recoverable errors were encountered during 6 of these C/C++ compilation units.

1854 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From jenkins at lists.osmocom.org  Fri Feb  9 10:19:13 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Fri, 9 Feb 2018 10:19:13 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #7
In-Reply-To: <1091562705.73.1518143427767.JavaMail.jenkins@jenkins.osmocom.org>
References: <1091562705.73.1518143427767.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <818242863.138.1518171553314.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/7/display/redirect>

------------------------------------------
[...truncated 817.53 KB...]
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for ANSI C header files... (cached) yes
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOGB... yes
checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes
checking for sysmocom/femtobts/superfemto.h... yes
checking whether to enable direct PHY access for PDCH of NuRAN Wireless Litecell 1.5 BTS... no
checking whether to enable VTY tests... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating osmo-pcu.pc
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating examples/Makefile
config.status: creating tests/Makefile
config.status: creating Makefile
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --enable-sysmocom-bts
+ make -j 8
Making all in include
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include'
Making all in src
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src'
  CXX      gprs_debug.lo
  CXX      csn1.lo
  CXX      gsm_rlcmac.lo
  CXX      gprs_rlcmac.lo
  CXX      gprs_bssgp_pcu.lo
  CXX      gprs_rlcmac_sched.lo
  CXX      gprs_rlcmac_ts_alloc.lo
  CXX      gprs_rlcmac_meas.lo
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac_meas.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac_meas.lo' failed
make[1]: *** [gprs_rlcmac_meas.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31:0,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/write_queue.h:31,
                 from ./pcu_l1_if.h:27,
                 from gprs_rlcmac.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac.lo' failed
make[1]: *** [gprs_rlcmac.lo] Error 1
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/prim.h:20,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gsm/l1sap.h:5,
                 from ./bts.h:31,
                 from gprs_rlcmac_ts_alloc.cpp:24:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
gprs_bssgp_pcu.cpp:967:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp]
 #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless"
  ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
gprs_bssgp_pcu.cpp: At global scope:
gprs_bssgp_pcu.cpp:76:12: warning: ?int parse_ra_cap(tlv_parsed*, MS_Radio_Access_capability_t*)? defined but not used [-Wunused-function]
 static int parse_ra_cap(struct tlv_parsed *tp, MS_Radio_Access_capability_t *rac)
            ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac_ts_alloc.lo' failed
make[1]: *** [gprs_rlcmac_ts_alloc.lo] Error 1
Makefile:775: recipe for target 'gprs_bssgp_pcu.lo' failed
make[1]: *** [gprs_bssgp_pcu.lo] Error 1
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l2(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:96:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l2(m) ((void *)(m->l2h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:516:22: note: in expansion of macro ?msgb_l2?
  return osmo_hexdump(msgb_l2(msg), msgb_l2len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10:0,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h: In function ?const char* msgb_hexdump_l3(const msgb*)?:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:98:21: error: invalid conversion from ?void*? to ?const unsigned char*? [-fpermissive]
 #define msgb_l3(m) ((void *)(m->l3h))
                    ~^~~~~~~~~~~~~~~~~
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:523:22: note: in expansion of macro ?msgb_l3?
  return osmo_hexdump(msgb_l3(msg), msgb_l3len(msg));
                      ^~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/msgb.h:24:0,
                 from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/gprs/gprs_ns.h:10,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_rlcmac_sched.cpp:20:
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/core/utils.h:55:7: note:   initializing argument 1 of ?char* osmo_hexdump(const unsigned char*, int)?
 char *osmo_hexdump(const unsigned char *buf, int len);
       ^~~~~~~~~~~~
Makefile:775: recipe for target 'gprs_rlcmac_sched.lo' failed
make[1]: *** [gprs_rlcmac_sched.lo] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src'
Makefile:461: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 1853 C/C++ compilation units (100%) successfully
[WARNING] Recoverable errors were encountered during 5 of these C/C++ compilation units.

1853 C/C++ compilation units (100%) are ready for analysis
 For more details, please look at: 
    /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure


From jenkins at lists.osmocom.org  Fri Feb  9 11:25:24 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Fri, 9 Feb 2018 11:25:24 +0000 (GMT)
Subject: Jenkins build is back to normal : Coverity-Upload
 (jenkins-job-builder) #8
In-Reply-To: <1091562705.73.1518143427767.JavaMail.jenkins@jenkins.osmocom.org>
References: <1091562705.73.1518143427767.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <1752672552.154.1518175524988.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/8/display/redirect?page=changes>



From holger at freyther.de  Sat Feb 10 16:21:19 2018
From: holger at freyther.de (Holger Freyther)
Date: Sat, 10 Feb 2018 16:21:19 +0000
Subject: Test please ignore..
Message-ID: <5BC47756-D4D3-489D-B38D-DD164A05A231@freyther.de>



From nhofmeyr at sysmocom.de  Mon Feb 12 15:23:44 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 12 Feb 2018 16:23:44 +0100
Subject: msc_vlr_tests patches
Message-ID: <20180212152344.GA13209@my.box>

Hi Max,

thanks for looking at the msc_vlr_tests.c. That 'while (0)' was a curious
artifact indeed :)

Some parts of it I actually wouldn't have liked to be merged:


1) pass nr as param / always print the test number.

The reason why I wanted that number output only in verbose mode is, I don't
want to adjust unrelated *.err output when adding a test in any position that
is not the last. The test nr was introduced only for running a specific test
manually, and for that the -v option provides the test number to whoever is
invoking it manually.

The individual tests do not at all need to know their number, so I would prefer
not passing it as parameter. The idea is to keep the manual invocation overhead
out of the production testing code.


2) pass IMSI as param / print the IMSI.

The IMSI used in the tests is (incidentally) the same throughout the tests and
doesn't really need to change in any way. It is but a local variable that
ensures there are no string constant typos within a test function.  It mayybe
could be one or more global string constants, but doesn't make sense as a
parameter passed to each and every test: some tests also (might) use two IMSIs.
Running the same tests with differing IMSIs is not needed, and I don't see a
patch introducing that. What was the idea there to justify the bloat?


(If we were to pass imsi and number to each and every msc_vlr_test* function,
it would be better to introduce a context struct that we can modify without
having to edit every function signature. But I'd prefer them parameter-less.)


3) you moved gsm_network creation into a separate function, but that function
is still called only once. So it's just cosmetic, or was there another purpose?

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180212/f900511a/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Feb 12 17:22:28 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 12 Feb 2018 18:22:28 +0100
Subject: spend time to properly separate handover 2?
Message-ID: <20180212172228.GB13209@my.box>

I'm on the load-based handover patches: it is adding a second handover decision
algorithm. What keeps slightly itching me about it is that it is not really
cleanly separate from the first (current) handover algorithm.

- For example, in the VTY, we have the 'handover algorithm (1|2)' command, and
  the 'handover *' namespace is shared between ho 1 and ho 2. So when I look at
  the VTY commands under 'handover', a considerable number of those apply only
  to handover algorithm 2, while some, like rxlev averaging window settings and
  similar, apply to both.  (I marked the ho2 ones in the VTY docs, but still)

- The patches also add penalty timers and ho failure counters in generic
  places. In ho algorithm 2, these penalty timers and failure counts are heeded
  and cause ho / assignment to be omitted if appropriate. Not so in ho1.

The point being, if we add a third, fourth, fifth HO algo at some point, this
would probably become a tad intransparent.

I wonder now whether I should spend time on jolly's patches to more cleanly
separate the two algorithms. For example, in the structs and code, more clearly
set and apply the penalty timers and failure counts *only* if ho algo 2 is
actually used, probably even moving all of it out to context structs only known
within the ho2 code.  (Otherwise, some code adds penalty timers which might
never be looked at or cleaned up until the conn is discarded..)

On the other hand, some shared concepts make sense to be re-used. If HO algo 3
(hypothetically) wants penalty timers as well, will separating merely amount to
code dup?

Do we want separate sets of parameters for ho1 and ho2? For example, for the
rxlev window averaging, is it better to have one setting used for both ho1 and
ho2, or do I expect each algo to remember its own rxlev averaging settings?

The current patch state kind of throws both in one pot; I tried to put some
struct members in a { }ho2 sub-struct, but it's a bit half-hearted. I'm
deciding back and forth.

Truly modularizing all of it would make for more code, like opaque struct
pointers to store context, specific to each ho algorithm, at e.g. subscr_conn;
and function callbacks to take actions in certain triggers (like setting a
penalty timer for ho failure); fully separate VTY namespaces for each algo. In
other words, a proper API, sort of like the auth algo code does. It is easier
to just patch it all in there and re-use existing members, but will that bite
us in the future...

Any thoughts?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180212/707411de/attachment.bin>

From pespin at sysmocom.de  Mon Feb 12 18:34:14 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 12 Feb 2018 19:34:14 +0100
Subject: spend time to properly separate handover 2?
In-Reply-To: <20180212172228.GB13209@my.box>
References: <20180212172228.GB13209@my.box>
Message-ID: <c27a07b9-8eb6-bcca-e2b5-56437e1dfb50@sysmocom.de>

Hi Neels,

As somebody which may have to dig into that code at some point in time 
in the future, I'd back the option of having an entire set of parameters 
separated for each algorithm, even if some of them are repeated. If some 
stuff is repeated, let's try to abstract it and use some helper 
functions + structs, API, whatever to help reduce duplicated code.
The reasoning behind it: if I'm interested in algorithm 1, I don't need 
to know related details or care about reading stuff from algorithms 
2..N, I just need to know the API and use or extend it if needed.

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


From msuraev at sysmocom.de  Tue Feb 13 13:17:17 2018
From: msuraev at sysmocom.de (Max)
Date: Tue, 13 Feb 2018 14:17:17 +0100
Subject: msc_vlr_tests patches
In-Reply-To: <20180212152344.GA13209@my.box>
References: <20180212152344.GA13209@my.box>
Message-ID: <ffabb3bc-eef9-014f-a264-5e9a4714f6ad@sysmocom.de>

Hi.


On 12.02.2018 16:23, Neels Hofmeyr wrote:
> thanks for looking at the msc_vlr_tests.c. That 'while (0)' was a curious
> artifact indeed :)

I didn't even thought it's a valid C code :)

> The reason why I wanted that number output only in verbose mode is, I don't
> want to adjust unrelated *.err output when adding a test in any position that
> is not the last.

Curious. When would we want to do that? I assumed tests are independent 
of each other. That's not the case?

> 2) pass IMSI as param / print the IMSI.
>
> The IMSI used in the tests is (incidentally) the same throughout the tests and
> doesn't really need to change in any way. It is but a local variable that
> ensures there are no string constant typos within a test function.  It mayybe
> could be one or more global string constants, but doesn't make sense as a
> parameter passed to each and every test: some tests also (might) use two IMSIs.
> Running the same tests with differing IMSIs is not needed, and I don't see a
> patch introducing that. What was the idea there to justify the bloat?

The idea is to make IMSI into actual parameter so it would be easy to 
introduce tests with different edge cases - shorter-than-normal, 
longer-than-normal IMSI etc. It have not materialized (yet?) though due 
to way too many hardcoded hex strings in tests.

> 3) you moved gsm_network creation into a separate function, but that function
> is still called only once. So it's just cosmetic, or was there another purpose?
>
See above.

-- 
- 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 Directors: Harald Welte



From laforge at gnumonks.org  Tue Feb 13 18:52:06 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Feb 2018 19:52:06 +0100
Subject: spend time to properly separate handover 2?
In-Reply-To: <20180212172228.GB13209@my.box>
References: <20180212172228.GB13209@my.box>
Message-ID: <20180213185206.GO13099@nataraja>

Hi Neels,

On Mon, Feb 12, 2018 at 06:22:28PM +0100, Neels Hofmeyr wrote:
> I'm on the load-based handover patches: it is adding a second handover decision
> algorithm. What keeps slightly itching me about it is that it is not really
> cleanly separate from the first (current) handover algorithm.

I think it's not worth worrying too much about that.

> The point being, if we add a third, fourth, fifth HO algo at some point, this
> would probably become a tad intransparent.

I think we can leave it as the burden to whoever will implement / contribute such additional
algorithms for the time being.  Our goal is to get Jolly's pending patches of a few
years finally merged, and not delay this by another month or so to invent new infrastructure
for hypothetical future additional algorithms.

> Do we want separate sets of parameters for ho1 and ho2? For example, for the
> rxlev window averaging, is it better to have one setting used for both ho1 and
> ho2, or do I expect each algo to remember its own rxlev averaging settings?

Let's keep it like it is (shared parameters shared, specific parameters specific)
 
-- 
- 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 ivan.kluchnikov at fairwaves.co  Tue Feb 13 19:01:11 2018
From: ivan.kluchnikov at fairwaves.co (Ivan Kluchnikov)
Date: Tue, 13 Feb 2018 22:01:11 +0300
Subject: fairwaves HO patches
In-Reply-To: <20180115214505.GC14510@my.box>
References: <gerrit.1486741011493.Iad3cf545b2f7e16276466cc37dd7a1e7858467e5@gerrit.osmocom.org>
 <20180115214505.GC14510@my.box>
Message-ID: <CA+QHiD-iLf_fiYu3SwommvsmTb_B+5rnE+VUGGD6FFNvSxfd_Q@mail.gmail.com>

Hello Neels,

Firstly, I want to start from the background of these patches, I think it
will help to understand their current status.
Some time ago we enabled HO on one of our production systems and figured
out that many calls were dropped or we had other issues during the handover
procedure.
We reproduced these cases in our lab and figured out that osmo-nitb didn't
handle HO procedure during the establishment of the call in a proper way.
We fixed issues for the cases which we saw in our production system, also I
tried to reproduce other HO issues during call establishing.
Unfortunately, I didn't implement any automated test suite for these HO
procedure cases.
For tests, I called bsc_handover_start function from different parts of the
code and for different states of the call and checked media and signalling
after and during HO procedure.
So one of the main improvement which should be implemented is an automated
test suite for HO procedure which will cover all stages of the call.

See my answers below:

2018-01-16 0:45 GMT+03:00 Neels Hofmeyr <nhofmeyr at sysmocom.de>:

> Hi Ivan,
>
> as I'm working towards load-based handover and incorporating your patches,
> I
> found that most of it is concerned with libmsc. In contrast, I am currently
> working on osmo-bsc, in libbsc, and would like to ask your advice.
>
> Some parts of the patch aren't easy to understand for me, and I'd like to
> make
> sure that I am not dismissing parts of it as non-applicable to libbsc even
> though they might be important.
>
> Since your patches were written, the code has changed. Now that we have the
> separate osmo-bsc, we will need two layers of handover: intra-BSC and
> inter-BSC.
>
> Intra-BSC is a handover between two cells that are serviced by the same
> BSC,
> and the higher layers (MSC) should not even notice that anything has
> happened
> -- MSC has asked the BSC to service a call by BSSAP Assignment, and the
> BSC is
> free to choose and change around the lchans it assigns to that. That is the
> layer I'm currently dug into.
>
> Inter-BSC is a handover between cells that are serviced by two different
> BSCs.
> That seems to be the land your patch is improving. The MSC is involved and
> so
> is MNCC.
>
> (Both MSC and BSC levels will need their own DTAP cache, and they are by
> definition completely independent -- MSC caches the DTAP coming from MNCC
> during Inter-BSC handover, BSC caches DTAP from MSC during Intra-BSC
> handover.)
>
> Since your patch is applied onto openbsc.git, where all of BSC and MSC are
> still one osmo-nitb, I want to make sure that I sort your patch right. Do
> some
> of its semantics apply to osmo-bsc master, even if the code changed?
>
> The smaller patches are either already applied to osmo-bsc master, or I've
> submitted them on gerrit just now:
>
>  handover_decision: Add more log messages to get more information about HO
> causes in logs
>  handover_decision: Fix condition for power budget handover attempt
>  handover_logic: set correct link to bts for subscriber_connection in case
> of moving this connection to another bts
>
> Remaining are a small and *the* complex one:
>
>  transaction: Add new function trans_find_by_lchan
>  handover: Implement proper handover procedure handling at any stage of
> the call
>
> Here is the last one with inline questions, I hope they are not too
> stupid; or
> too long, it ended up being a lot to read. Thanks in advance for taking a
> look:
>
>
> > commit f7f4dc5e3b0dd61b8322946597147baef5d0464b
> > Author: Ivan Kluchnikov <kluchnikovi at gmail.com>
> > Date:   Wed Aug 23 18:09:50 2017 +0300
> >
> >     handover: Implement proper handover procedure handling at any stage
> of the call
> >
> >     Enhancements for each stage of handover procedure should be
> implemented in order to support handover at any stage of the call.
> >     For these purposes new in_handover state and ho_queue for call
> control messages was introduced for gsm_subscriber_connection.
> >
> >     Stage 1: HO-Command is sent to MS
> >     gsm_subscriber_connection state should be changed to in_handover=1.
> >     In this state all transmission of signalling layer messages (except
> RR messages needed for handover procedure)
> >     should be suspended until resuming is indicated.
> >     All call control messages for connection received from network side
> should be buffered in ho_queue.
> >     All call control messages for connection received from MS side
> should be ignored.
> >     Channel mode modification procedures should be also suspended.
> >
> >     Stage 2: HO-Detect is received from MS
> >     Audio path should be switched on network side.
> >
> >     Stage 3-1: HO-Complete is received from MS
> >     Resumption procedure after successful handover should be performed:
> >      - gsm_subscriber_connection state should be changed to normal
> (in_handover=0).
> >      - all buffered call control messages (ho_queue) should be sent to
> MS on new lchan.
> >      - suspended channel mode modification procedures should be
> performed on new lchan.
> >
> >     Stage 3-2: HO-Fail is received from MS
> >     Resumption procedure after failed handover should be performed:
> >      - gsm_subscriber_connection state should be changed to normal
> (in_handover=0).
> >      - all buffered call control messages (ho_queue) should be sent to
> MS on old lchan.
> >      - suspended channel mode modification procedures should be
> performed on old lchan.
> >
> >     Stage 3-3: T3103 expired: Handover has failed without HO-Complete or
> HO-Fail
> >     Resumption procedure should not be performed in case of T3103
> expired:
> >      - gsm_subscriber_connection state should be changed to normal
> (in_handover=0).
> >      - all buffered call control messages (ho_queue) should be cleaned
> without sending them to MS.
> >      - suspended channel mode modification procedures should not be
> performed.
> >
> >     Change-Id: Icb9b5c35ef0c894af2ea762e539f1a9216447fb7
> >
> > diff --git a/openbsc/include/openbsc/bsc_api.h
> b/openbsc/include/openbsc/bsc_api.h
> > index 3a931199..baacbeda 100644
> > --- a/openbsc/include/openbsc/bsc_api.h
> > +++ b/openbsc/include/openbsc/bsc_api.h
> > @@ -51,5 +51,6 @@ int gsm0808_cipher_mode(struct
> gsm_subscriber_connection *conn, int cipher,
> >  int gsm0808_page(struct gsm_bts *bts, unsigned int page_group,
> >                unsigned int mi_len, uint8_t *mi, int chan_type);
> >  int gsm0808_clear(struct gsm_subscriber_connection *conn);
> > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn);
> >
> >  #endif
> > diff --git a/openbsc/include/openbsc/gsm_data.h
> b/openbsc/include/openbsc/gsm_data.h
> > index ac573c49..542b2611 100644
> > --- a/openbsc/include/openbsc/gsm_data.h
> > +++ b/openbsc/include/openbsc/gsm_data.h
> > @@ -138,6 +138,8 @@ struct gsm_subscriber_connection {
> >       struct gsm_network *network;
> >
> >       int in_release;
> > +     int in_handover;
> > +     struct llist_head ho_queue;
> >       struct gsm_lchan *lchan; /* BSC */
> >       struct gsm_lchan *ho_lchan; /* BSC */
> >       struct gsm_bts *bts; /* BSC */
> > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
> > index 8a4c85ff..71e82d03 100644
> > --- a/openbsc/src/libbsc/bsc_api.c
> > +++ b/openbsc/src/libbsc/bsc_api.c
> > @@ -253,11 +253,14 @@ struct gsm_subscriber_connection
> *bsc_subscr_con_allocate(struct gsm_lchan *lcha
> >       conn->bts = lchan->ts->trx->bts;
> >       lchan->conn = conn;
> >       llist_add_tail(&conn->entry, &net->subscr_conns);
> > +     INIT_LLIST_HEAD(&conn->ho_queue);
> >       return conn;
> >  }
> >
> >  void bsc_subscr_con_free(struct gsm_subscriber_connection *conn)
> >  {
> > +     struct msgb *msg;
> > +
> >       if (!conn)
> >               return;
> >
> > @@ -283,6 +286,11 @@ void bsc_subscr_con_free(struct
> gsm_subscriber_connection *conn)
> >               conn->secondary_lchan->conn = NULL;
> >       }
> >
> > +     while (!llist_empty(&conn->ho_queue)) {
> > +             msg = msgb_dequeue(&conn->ho_queue);
> > +             msgb_free(msg);
> > +     }
> > +
> >       llist_del(&conn->entry);
> >       talloc_free(conn);
> >  }
> > @@ -747,6 +755,17 @@ int gsm0808_clear(struct gsm_subscriber_connection
> *conn)
> >       return 0;
> >  }
> >
> > +/*
> > + * Release handover RF Channel.
> > + */
> > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn)
> > +{
> > +     if (conn->ho_lchan)
> > +             bsc_clear_handover(conn, 1);
> > +
> > +     return 0;
> > +}
> > +
> >  static void send_sapi_reject(struct gsm_subscriber_connection *conn,
> int link_id)
> >  {
> >       struct bsc_api *api;
> > diff --git a/openbsc/src/libbsc/handover_logic.c
> b/openbsc/src/libbsc/handover_logic.c
> > index af4e8013..b7085c34 100644
> > --- a/openbsc/src/libbsc/handover_logic.c
> > +++ b/openbsc/src/libbsc/handover_logic.c
> > @@ -186,10 +186,17 @@ static void ho_T3103_cb(void *_ho)
> >  {
> >       struct bsc_handover *ho = _ho;
> >       struct gsm_network *net = ho->new_lchan->ts->trx->bts->network;
> > +     struct msgb *msg;
> >
> >       DEBUGP(DHO, "HO T3103 expired\n");
> >       rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_TIMEOUT]);
> >
> > +     ho->new_lchan->conn->in_handover = 0;
> > +     while (!llist_empty(&ho->new_lchan->conn->ho_queue)) {
> > +             msg = msgb_dequeue(&ho->new_lchan->conn->ho_queue);
> > +             msgb_free(msg);
> > +     }
> > +
>
> (Your ho_queue seems to live in libbsc, while most of the patch seems to be
> concerned with libmsc. But nevermind, from jolly's patches I already have a
> similar queue in osmo-bsc, and we'll probably use yours for libmsc.)
>


It's ok, as you wrote above, we should have a queue in osmo-bsc and in
libmsc.


>
> >       ho->new_lchan->conn->ho_lchan = NULL;
> >       ho->new_lchan->conn = NULL;
> >       lchan_release(ho->new_lchan, 0, RSL_REL_LOCAL_END);
> > @@ -214,6 +221,8 @@ static int ho_chan_activ_ack(struct gsm_lchan
> *new_lchan)
> >
> >       gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref);
> >
> > +     new_lchan->conn->in_handover = 1;
> > +
>
> In current osmo-bsc master, we already set conn->ho_lchan before sending
> out
> the chan activation request. I'd actually assume setting the flag only now,
> after the activ ack, is a bit too late?


I set it right after gsm48_send_ho_cmd, because sending of HO CMD is the
actual start of handover procedure (as I understand specs).


> >       /* start T3103.  We can continue either with T3103 expiration,
> >        * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */
> >       ho->T3103.cb = ho_T3103_cb;
> > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan
> *new_lchan)
> >       osmo_timer_schedule(&ho->T3103, 10, 0);
> >
> >       /* create a RTP connection */
> > -     if (is_ipaccess_bts(new_lchan->ts->trx->bts))
> > +     if (is_ipaccess_bts(new_lchan->ts->trx->bts) &&
> > +                                     new_lchan->tch_mode !=
> GSM48_CMODE_SIGN)
> >               rsl_ipacc_crcx(new_lchan);
>
> Please explain ... what case / behavior is this fixing?
> Do we ever see CMODE_SIGN handovers?
> Would we also need to check for GSM48_CMODE_DATA_*?
>

Yes, handover can be initiated in any mode of lchan and we saw handovers
for lchans in GSM48_CMODE_SIGN mode.
So I think we should be able to cover this case because I didn't find any
mention in the specs that this case is prohibited for HO.
I don't know if HO is allowed for CSD (GSM48_CMODE_DATA_*), it should be
checked.
But if it is prohibited for CSD, I think we should check and block it on
the stage of bsc_handover_start or earlier.


>
> > @@ -273,6 +283,11 @@ static int ho_gsm48_ho_compl(struct gsm_lchan
> *new_lchan)
> >       if (is_e1_bts(new_lchan->conn->bts))
> >               switch_trau_mux(ho->old_lchan, new_lchan);
> >
> > +     if (ho->old_lchan->conn->mncc_rtp_connect_pending) {
> > +             new_lchan->abis_ip.connect_port = ho->old_lchan->abis_ip.
> connect_port;
> > +             new_lchan->abis_ip.connect_ip = ho->old_lchan->abis_ip.
> connect_ip;
> > +     }
> > +
>
> So if an RTP connect to MNCC is pending, we copy the old lchan's RTP port
> and
> IP? Which is this, the MNCC / call router side IP and port?
>

Yes, Remote (MGW) IP address and port for RTP.
We set them in tch_rtp_connect function:
  trans->conn->mncc_rtp_connect_pending = 1;
 + if (trans->conn->in_handover) {
 + lchan->abis_ip.connect_port = rtp->port;
 + lchan->abis_ip.connect_ip = rtp->ip;
 + return 0;
 + }
  return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0);
  }


> Why not set this at the initiation of the HO already?
>

We can't set this at the initiation of the HO because it is possible that
we don't have port and IP of the remote part at the HO initiation, and we
can get them during HO procedure (in "parallel" with HO procedure), as you
can see in tch_rtp_connect function above.



>
> > @@ -295,27 +310,9 @@ static int ho_gsm48_ho_compl(struct gsm_lchan
> *new_lchan)
> >  static int ho_gsm48_ho_fail(struct gsm_lchan *old_lchan)
> >  {
> >       struct gsm_network *net = old_lchan->ts->trx->bts->network;
> > -     struct bsc_handover *ho;
> > -     struct gsm_lchan *new_lchan;
> > -
> > -     ho = bsc_ho_by_old_lchan(old_lchan);
> > -     if (!ho) {
> > -             LOGP(DHO, LOGL_ERROR, "unable to find HO record\n");
> > -             return -ENODEV;
> > -     }
> >
> >       rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_FAILED]);
> >
> > -     new_lchan = ho->new_lchan;
> > -
> > -     /* release the channel and forget about it */
> > -     ho->new_lchan->conn->ho_lchan = NULL;
> > -     ho->new_lchan->conn = NULL;
> > -     handover_free(ho);
> > -
> > -     lchan_release(new_lchan, 0, RSL_REL_LOCAL_END);
> > -
> > -
>
> I'm puzzled by this removal. No actions during ho_fail? Is this really
> intended, or just some rebase artifact?
>

It was before the split of the code, so I moved it to
openbsc/src/libmsc/gsm_04_08.c:
+static int ho_fail(struct gsm_lchan *old_lchan)
 +{
 + struct gsm_trans *trans;
 +
 + old_lchan->conn->in_handover = 0;
 + trans = trans_find_by_lchan(old_lchan);
 + if (trans)
 + ho_resumption(old_lchan, trans);
 + else {
 + LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for old_lchan.\n",
 + gsm_lchan_name(old_lchan));
 + ho_queue_clean(old_lchan->conn);
  }
 + gsm0808_ho_clear(old_lchan->conn);
 + return 0;
 +}


>
> >       return 0;
> >  }
> >
> > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_
> 08.c
> > index e5402d0a..84338d72 100644
> > --- a/openbsc/src/libmsc/gsm_04_08.c
> > +++ b/openbsc/src/libmsc/gsm_04_08.c
> > @@ -147,6 +147,15 @@ static int gsm48_conn_sendmsg(struct msgb *msg,
> struct gsm_subscriber_connection
> >                               sign_link->trx->bts->nr,
> >                               sign_link->trx->nr, msg->lchan->ts->nr,
> >                               gh->proto_discr, gh->msg_type);
> > +
> > +             if (conn->in_handover) {
> > +                     msgb_enqueue(&conn->ho_queue, msg);
> > +                     DEBUGP(DCC, "(bts %d trx %d ts %d) Suspend message
> sending to MS, "
> > +                             "active HO procedure.\n",
> > +                             sign_link->trx->bts->nr,
> > +                             sign_link->trx->nr, msg->lchan->ts->nr);
> > +                     return 0;
> > +             }
>
> (here DTAP handled in libmsc ends up in the ho_queue that otherwise seems
> to
> live in libbsc ... as I said above this queue will probably move to libmsc
> altogether to become part of osmo-msc master.)
>

Ok.

 >       }

> >
> >       return gsm0808_submit_dtap(conn, msg, 0, 0);
> > @@ -1749,11 +1758,8 @@ static int switch_for_handover(struct gsm_lchan
> *old_lchan,
> >       struct rtp_socket *old_rs, *new_rs, *other_rs;
> >
> >       /* Ask the new socket to send to the already known port. */
> > -     if (new_lchan->conn->mncc_rtp_bridge) {
> > -             LOGP(DHO, LOGL_DEBUG, "Forwarding RTP\n");
> > -             rsl_ipacc_mdcx(new_lchan,
> > -                                     old_lchan->abis_ip.connect_ip,
> > -                                     old_lchan->abis_ip.connect_port,
> 0);
> > +     if (new_lchan->ts->trx->bts->network->mncc_state) {
> > +             /* Audio path should be switched after receiving ho detect
> message.*/
> >               return 0;
> >       }
>
> I notice that in the current head, the entire switch_for_handover() has
> been
> dropped; it was doing libbsc lchan stuff from within libmsc. Hence we must
> have
> added similar logic in osmo-bsc.git and completely dropped this.
>
>
Yes, it is correct.



> I think the commit re-implementing handover in osmo-bsc is
> http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f9
> 2b7ccf175a
>
> It appears that lchan->abis_ip.connect_ip and connect_port aren't used at
> all
> in osmo-bsc master, but are still present in the struct. I'll ask others
> about
> that.
>
> In any case, the code base has changed substantially, and this patch hunk
> no
> longer applies at all.
>
> Am I interpreting this hunk correctly: it moves the ipacc_mdcx to tell the
> new
> lchan about its RTP peer to a later stage?
>

Yes, we call rsl_ipacc_mdcx function after receiving ho detect message.
See ho_detect function in openbsc/src/libmsc/gsm_04_08.c:
+static int ho_detect(struct gsm_lchan *new_lchan)
 +{
 + struct gsm_trans *trans;
 + struct gsm_lchan *old_lchan;
 +
 + trans = trans_find_by_lchan(new_lchan);
 +
 + if (!trans) {
 + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan"
 + " with enabled tch_recv.\n",
 + gsm_lchan_name(new_lchan));
 + return 0;
 + }
 +
 + if (!new_lchan->conn->mncc_rtp_bridge) {
 + LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not in
mncc_rtp_bridge mode.\n",
 + gsm_lchan_name(new_lchan));
 + return 0;
 + }
 +
 + old_lchan = bsc_handover_pending(new_lchan);
 + if (!old_lchan) {
 + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan for handover.\n",
 + gsm_lchan_name(new_lchan));
 + return 0;
 + }
 +
 + LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n");
 + rsl_ipacc_mdcx(new_lchan,
 + old_lchan->abis_ip.connect_ip,
 + old_lchan->abis_ip.connect_port, 0);
 +
 + mncc_recv_rtp_modify(new_lchan, trans->callref);
 +
  return 0;
  }



> In current osmo-bsc master, it seems that this ipacc_mdcx happens as soon
> as
> the ipacc_crcx is complete, seen in osmo-bsc/src/osmo-bsc/osmo_bsc_audio.c
> in
> handle_abisip_signal(), always using the IP:port the MSC sent us.
>
>
I am not sure that it is the proper place for calling rsl_ipacc_mdcx in
case of handover, as I understand spec, we should switch media path only
after receiving ho detect message, but it should be checked.



> >
> > @@ -1821,8 +1827,10 @@ static int handle_abisip_signal(unsigned int
> subsys, unsigned int signal,
> >       if (subsys != SS_ABISIP)
> >               return 0;
> >
> > +     net = lchan->ts->trx->bts->network;
> > +
> >       /* RTP bridge handling */
> > -     if (lchan->conn && lchan->conn->mncc_rtp_bridge)
> > +     if (lchan->conn && net->mncc_state)
> >               return tch_rtp_signal(lchan, signal);
>
> What are the semantics here? It seems odd to move from a check of a
> conn-specific state (conn->mncc_rtp_bridge) to a check of a global value
> (net->mncc_state).
>

Hm, yes, it seems odd for this case.


>
> In any case, this is MNCC related and should not impact Intra-BSC handover,
> right?
>

Yes, it is MNCC related only.


>
> >
> >       /* in case we use direct BTS-to-BTS RTP */
> > @@ -1851,7 +1859,6 @@ static int handle_abisip_signal(unsigned int
> subsys, unsigned int signal,
> >
> >               /* check if any transactions on this lchan still have
> >                * a tch_recv_mncc request pending */
> > -             net = lchan->ts->trx->bts->network;
> >               llist_for_each_entry(trans, &net->trans_list, entry) {
> >                       if (trans->conn && trans->conn->lchan == lchan &&
> trans->tch_recv) {
> >                               DEBUGP(DCC, "pending tch_recv_mncc
> request\n");
> > @@ -2017,6 +2024,13 @@ static int tch_recv_mncc(struct gsm_network *net,
> uint32_t callref, int enable)
> >          switch (bts->type) {
> >          case GSM_BTS_TYPE_NANOBTS:
> >          case GSM_BTS_TYPE_OSMO_SYSMO:
> >               if (ipacc_rtp_direct) {
> >                       LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is
> disabled\n");
> >                       return -EINVAL;
> >               }
> > +             /* RTP bridge handling */
> > +             if (lchan->conn && net->mncc_state) {
> > +                     return 0;
> > +             }
>
> If we have a conn and using external MNCC, don't continue at all? I'm not
> following, would be nice if the comment explained why we need to drop out
> here.
>
> (added some more code context manually)
>


Yes, in this case, we set trans->tch_recv only in the code above.
In case of mncc bridge mode, audio socket creating and connecting are
handled in tch_rtp_create and tch_rtp_connect functions (handlers of
MNCC_RTP_CREATE and MNCC_RTP_CONNECT messages).


> >               /* In case, we don't have a RTP socket to the BTS yet, the
> BTS
> >               * will not be connected to our RTP proxy and the socket
> will
> >               * not be assigned to the application interface. This method
> >               * will be called again, once the audio socket is created
> and
> >               * connected. */
> >               if (!lchan->abis_ip.rtp_socket) {
> >                       DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n",
> enable);
> >                       return 0;
> >               }
> >               if (enable) {
> >                       /* connect the TCH's to our RTP proxy */
> >                       rc = rsl_ipacc_mdcx_to_rtpsock(lchan);
> >                       if (rc < 0)
> >                               return rc;
> >                       /* assign socket to application interface */
> >                       rtp_socket_upstream(lchan->abis_ip.rtp_socket,
> >                               net, callref);
> >               } else
> >                       rtp_socket_upstream(lchan->abis_ip.rtp_socket,
> >                               net, 0);
> >               break;
> >
>
>
>
> > @@ -3325,6 +3339,41 @@ static void mncc_recv_rtp_err(struct gsm_network
> *net, uint32_t callref, int cmd
> >       return mncc_recv_rtp(net, callref, cmd, 0, 0, 0, 0);
> >  }
> >
> > +static void mncc_recv_rtp_modify(struct gsm_lchan *lchan, uint32_t
> callref)
>
> This is to tell the call router that the payload type has changed, right?


Yes.


>   I've
> asked in the redmine about whether/how we'd convey an RTP payload change
> to the
> MNCC in case of an Intra-BSC handover...
>
> https://osmocom.org/issues/1606#note-45
>
>
Ok, I will check this issue.


> > +{
> > +     int msg_type;
> > +     struct gsm_network *net = lchan->ts->trx->bts->network;
> > +
> > +     LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP modify ind.\n",
> > +             gsm_lchan_name(lchan));
> > +
> > +     switch (lchan->abis_ip.rtp_payload) {
> > +     case RTP_PT_GSM_FULL:
> > +             msg_type = GSM_TCHF_FRAME;
> > +             break;
> > +     case RTP_PT_GSM_EFR:
> > +             msg_type = GSM_TCHF_FRAME_EFR;
> > +             break;
> > +     case RTP_PT_GSM_HALF:
> > +             msg_type = GSM_TCHH_FRAME;
> > +             break;
> > +     case RTP_PT_AMR:
> > +             msg_type = GSM_TCH_FRAME_AMR;
> > +             break;
> > +     default:
> > +             LOGP(DMNCC, LOGL_ERROR, "%s unknown payload type %d\n",
> > +                     gsm_lchan_name(lchan), lchan->abis_ip.rtp_payload);
> > +             msg_type = 0;
> > +             break;
> > +     }
> > +
> > +     mncc_recv_rtp(net, callref, MNCC_RTP_MODIFY,
> > +                     lchan->abis_ip.bound_ip,
> > +                     lchan->abis_ip.bound_port,
> > +                     lchan->abis_ip.rtp_payload,
> > +                     msg_type);
> > +}
> > +
> >  static int tch_rtp_create(struct gsm_network *net, uint32_t callref)
> >  {
> >       struct gsm_bts *bts;
> > @@ -3374,6 +3423,9 @@ static int tch_rtp_create(struct gsm_network *net,
> uint32_t callref)
> >               LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s,
> chan_type=%s\n",
> >                    get_value_string(gsm48_chan_mode_names, m),
> >                    get_value_string(gsm_chan_t_names, lchan->type));
> > +             if (trans->conn->in_handover) {
> > +                     return 0;
> > +             }
>
> Am I reading right: if we're doing handover, the MSC shouldn't sent another
> BSSAP Assignment to the BSC; instead, the BSC level figures out another
> lchan
> and done ... ?
>

I will add some context:

  if (lchan->tch_mode == GSM48_CMODE_SIGN) {
  trans->conn->mncc_rtp_create_pending = 1;
  m = mncc_codec_for_mode(lchan->type);
  LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s, chan_type=%s\n",
      get_value_string(gsm48_chan_mode_names, m),
      get_value_string(gsm_chan_t_names, lchan->type));
 + if (trans->conn->in_handover) {
 + return 0;
 + }
  return gsm0808_assign_req(trans->conn, m,
  lchan->type != GSM_LCHAN_TCH_H);
  }

As I understand, MSC can send sent another BSSAP Assignment to the BSC, but
it doesn't make sense to send it to MS during a handover procedure, so it
should be cached and send after handover.
In our implementation, we call gsm0808_assign_req for new lchan in the code
below, when HO is completed and mncc_rtp_create_pending = 1.


>
> >               return gsm0808_assign_req(trans->conn, m,
> >                               lchan->type != GSM_LCHAN_TCH_H);
> >       }
> > @@ -3420,23 +3472,21 @@ static int tch_rtp_connect(struct gsm_network
> *net, void *arg)
> >        * same package!
> >        */
> >       trans->conn->mncc_rtp_connect_pending = 1;
> > +     if (trans->conn->in_handover) {
> > +             lchan->abis_ip.connect_port = rtp->port;
> > +             lchan->abis_ip.connect_ip = rtp->ip;
> > +             return 0;
> > +     }
> >       return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0);
>
> We're not telling the BTS about the call router's IP:port anymore?
> Please explain...
>
>
The same idea as above, it doesn't make sense to send it to old lchan
during a handover procedure, so it should be cached and send after handover.
In our implementation we call rsl_ipacc_mdcx for new lchan in the code
below, when HO is completed and mncc_rtp_connect_pending = 1.


> >  }
> >
> >  static int tch_rtp_signal(struct gsm_lchan *lchan, int signal)
> >  {
> >       struct gsm_network *net;
> > -     struct gsm_trans *tmp, *trans = NULL;
> > +     struct gsm_trans *trans;
> >
> >       net = lchan->ts->trx->bts->network;
> > -     llist_for_each_entry(tmp, &net->trans_list, entry) {
> > -             if (!tmp->conn)
> > -                     continue;
> > -             if (tmp->conn->lchan != lchan && tmp->conn->ho_lchan !=
> lchan)
> > -                     continue;
> > -             trans = tmp;
> > -             break;
> > -     }
> > +     trans = trans_find_by_lchan(lchan);
> >
> >       if (!trans) {
> >               LOGP(DMNCC, LOGL_ERROR, "%s IPA abis signal but no
> transaction.\n",
> > @@ -3459,7 +3509,7 @@ static int tch_rtp_signal(struct gsm_lchan *lchan,
> int signal)
> >               maybe_switch_for_handover(lchan);
> >               break;
> >       case S_ABISIP_MDCX_ACK:
> > -             if (lchan->conn->mncc_rtp_connect_pending) {
> > +             if (lchan->conn->mncc_rtp_connect_pending &&
> !lchan->conn->in_handover) {
>
> if we're in handover, we don't need to tell MNCC that RTP got connected,
> because that already happened when the call got established initially?
> So mncc_rtp_connect_pending has a second meaning during handover?
>

Yes, as I wrote above, mncc_rtp_connect_pending during handover means that
we cached call of rsl_ipacc_mdcx function and should call it after
handover.



>
> >                       lchan->conn->mncc_rtp_connect_pending = 0;
> >                       LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP
> connect ind.\n",
> >                               gsm_lchan_name(lchan));
> >                       mncc_recv_rtp_sock(net, trans, MNCC_RTP_CONNECT);
> >               }
> >               break;
>
> > @@ -3471,6 +3521,134 @@ static int tch_rtp_signal(struct gsm_lchan
> *lchan, int signal)
> >       return 0;
> >  }
> >
> > +static void ho_queue_clean(struct gsm_subscriber_connection *conn)
> > +{
> > +     struct msgb *msg;
> > +     while (!llist_empty(&conn->ho_queue)) {
> > +             msg = msgb_dequeue(&conn->ho_queue);
> > +             msgb_free(msg);
> > +     }
> > +}
> > +
> > +static void ho_resumption(struct gsm_lchan *lchan, struct gsm_trans
> *trans)
> > +{
> > +     struct msgb *msg;
> > +     enum gsm48_chan_mode m;
> > +
> > +     while (!llist_empty(&lchan->conn->ho_queue)) {
> > +             msg = msgb_dequeue(&lchan->conn->ho_queue);
> > +             gsm48_conn_sendmsg(msg, lchan->conn, trans);
> > +     }
> > +
> > +     if (trans->conn->mncc_rtp_create_pending &&
> > +                                     lchan->tch_mode ==
> GSM48_CMODE_SIGN) {
> > +       m = mncc_codec_for_mode(lchan->type);
> > +       gsm0808_assign_req(lchan->conn, m, lchan->type !=
> GSM_LCHAN_TCH_H);
>
> Wait, now we *do* send a BSSAP Assignment after all?
> (excuse if I'm being noob, I'm still finding my way through handover in
> general)
>

Yes, at this stage we have "cached" BSSAP Assignment (because of
mncc_rtp_create_pending=1).
HO was completed, so we send "cached" BSSAP Assignment for the new lchan.


>
> shouldn't we rather dequeue the cached DTAP after this instead of before?
>

It is a good question because for my tests it was ok, but I am not sure the
current version of the code covered all use cases, so it is better to check.

> +  }
> > +
> > +     if (trans->conn->mncc_rtp_connect_pending) {
> > +             rsl_ipacc_mdcx(lchan, lchan->abis_ip.connect_ip,
> lchan->abis_ip.connect_port, 0);
> > +     }
> > +}
> > +
> > +static int ho_complete(struct gsm_lchan *new_lchan)
> > +{
> > +     struct gsm_trans *trans;
> > +
> > +     new_lchan->conn->in_handover = 0;
> > +     trans = trans_find_by_lchan(new_lchan);
> > +     if (!trans) {
> > +             LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction
> for new_lchan.\n",
> > +                     gsm_lchan_name(new_lchan));
> > +             ho_queue_clean(new_lchan->conn);
> > +             return 0;
> > +     }
> > +
> > +     ho_resumption(new_lchan, trans);
> > +     return 0;
> > +}
> > +
> > +static int ho_fail(struct gsm_lchan *old_lchan)
> > +{
> > +     struct gsm_trans *trans;
> > +
> > +     old_lchan->conn->in_handover = 0;
> > +     trans = trans_find_by_lchan(old_lchan);
> > +     if (trans)
> > +             ho_resumption(old_lchan, trans);
> > +     else {
> > +             LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for
> old_lchan.\n",
> > +                     gsm_lchan_name(old_lchan));
> > +             ho_queue_clean(old_lchan->conn);
> > +     }
> > +
> > +     gsm0808_ho_clear(old_lchan->conn);
> > +     return 0;
> > +}
> > +
> > +static int ho_detect(struct gsm_lchan *new_lchan)
> > +{
> > +     struct gsm_trans *trans;
> > +     struct gsm_lchan *old_lchan;
> > +
> > +     trans = trans_find_by_lchan(new_lchan);
> > +
> > +     if (!trans) {
> > +             LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction
> for new_lchan"
> > +                     " with enabled tch_recv.\n",
> > +                     gsm_lchan_name(new_lchan));
> > +             return 0;
> > +     }
> > +
> > +     if (!new_lchan->conn->mncc_rtp_bridge) {
> > +             LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not
> in mncc_rtp_bridge mode.\n",
> > +                     gsm_lchan_name(new_lchan));
> > +             return 0;
> > +     }
> > +
> > +     old_lchan = bsc_handover_pending(new_lchan);
> > +     if (!old_lchan) {
> > +             LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan
> for handover.\n",
> > +                     gsm_lchan_name(new_lchan));
> > +             return 0;
> > +     }
> > +
> > +     LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n");
> > +     rsl_ipacc_mdcx(new_lchan,
> > +                             old_lchan->abis_ip.connect_ip,
> > +                             old_lchan->abis_ip.connect_port, 0);
> > +
> > +     mncc_recv_rtp_modify(new_lchan, trans->callref);
> > +
> > +     return 0;
> > +}
> > +
> > +/* some other part of the code sends us a signal */
> > +static int handle_lchan_signal(unsigned int subsys, unsigned int signal,
> > +                              void *handler_data, void *signal_data)
> > +{
> > +     struct lchan_signal_data *lchan_data;
> > +     struct gsm_lchan *lchan;
> > +
> > +     lchan_data = signal_data;
> > +     switch (subsys) {
> > +     case SS_LCHAN:
> > +             lchan = lchan_data->lchan;
> > +             if (!lchan->conn)
> > +                     return 0;
> > +             switch (signal) {
> > +             case S_LCHAN_HANDOVER_DETECT:
> > +               return ho_detect(lchan);
> > +             case S_LCHAN_HANDOVER_COMPL:
> > +               return ho_complete(lchan);
> > +             case S_LCHAN_HANDOVER_FAIL:
> > +                     return ho_fail(lchan);
> > +             }
> > +             break;
> > +     }
> > +
> > +     return 0;
> > +}
> >
> >  static struct downstate {
> >       uint32_t        states;
> > @@ -3853,6 +4031,11 @@ static int gsm0408_rcv_cc(struct
> gsm_subscriber_connection *conn, struct msgb *m
> >               gsm48_cc_msg_name(msg_type), trans?(trans->cc.state):0,
> >               gsm48_cc_state_name(trans?(trans->cc.state):0));
> >
> > +     if (conn->in_handover) {
> > +             DEBUGP(DCC, "Message unhandled, handover procedure.\n");
> > +             return 0;
> > +     }
> > +
>
> If in handover, drop all CC on the floor?
>
> How about a call release, i.e. I hang up while I'm coincidentally being
> handovered?
>
>
Yes, the same issue, it worked ok for my tests, but we should test and
check all cases.

>       /* Create transaction */
> >       if (!trans) {
> >               DEBUGP(DCC, "Unknown transaction ID %x, "
> >
> >
> >
>
>
> Thanks again!
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180213/85fa9e63/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180213/85fa9e63/attachment.bin>

From michau.benoit at gmail.com  Tue Feb 13 21:33:14 2018
From: michau.benoit at gmail.com (benoit michau)
Date: Tue, 13 Feb 2018 22:33:14 +0100
Subject: 3G femtocells and core network in Python
Message-ID: <CAOB3c4EHSgOn0toC=t_sbxJBKB-S+DEM6MWhmmXG1507U7VRPA@mail.gmail.com>

Dear osmocom people,

here is a quick email to announce the initial release (or more
exactly, an update) of the "corenet" application I have been working
on those last months. It is basically a 3G and 4G core network,
entirely written in Python: it handles 3G femtocells and 4G eNodeBs,
and handsets connecting through them.

The 3G part has been made possible thanks to the accelerate3g5 program
of last year. I wanted also to thank the people running the osmocom
community and the sysmocom company.

More information is available here:
https://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5_--_benoit
And the application itself is available on github:
https://github.com/mitshell/corenet/

Do not hesitate to test it and to provide any feedback.
Benoit


From laforge at gnumonks.org  Wed Feb 14 08:41:11 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Feb 2018 09:41:11 +0100
Subject: Warning: OsmoMSC config file / VTY changes
Message-ID: <20180214084110.GT13099@nataraja>

Dear all,

please note that some obsolete VTY commands have been removed from
osmo-msc last night,, so in case your configs are no longer parsed, have
a look at the recent changes to doc/examples/osmo-msc/osmo-msc.cfg which
will point you to:

-  auth policy closed
-  location updating reject cause 13

Those really serve no purpose at all in OsmoMSC anymore, and I think
it's better to remove them completely rather than silently accept them
for "compatibility reasons".  This is of course debatable, if somebody
has better suggestion.

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 n.kremeris at live.com  Wed Feb 14 16:06:33 2018
From: n.kremeris at live.com (Norbertas Kremeris)
Date: Wed, 14 Feb 2018 16:06:33 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection (using
 LimeSDR)
Message-ID: <DB6PR0902MB192699B79D512CE749346092FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>

Hello all,

I have run into some problems while building and running osmo-nitb, 
osmo-bts-trx and osmo-trx on Ubuntu 16.04. I am trying to create a 
self-contained gsm network box. I have successfully built libosmocore, 
libosmo-abis, libosmo-netif, libosmo-sccp, openbsc, osmo-bts and 
osmo-trx all from git sources, and i am also using linux call router. 
All make checks pass corrently without issues.

As for the SDR side, i am have the latest UHD, SoapySDR and SoapyUHD, 
and latest LimeSuite library for LimeSDR support.

SMS send/receive works correctly without any issues. Calling, however, 
works neither with osmo-nitb as standalone, neither with osmo-nitb with 
-m parameter + LCR. when trying to call, the receiving phone rings, but 
when trying to answer it randomly either gets stuck and does not answer, 
drops the call instantly or actually takes the call (and the elapsed 
seconds counter starts counting), but all you can hear is random noises 
coming both from the calling and from receiving phones, while the 
calling phone still shows that the call has not been answered, as in 
still calling.

this is the debug info from osmo-trx:

<0000> rsl.c:606 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
<0011> lapd_core.c:920 Store content res. (dl=0xb668cec8)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12405
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 
(dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0000> rsl.c:606 (bts=0,trx=0,ts=3,ss=0) Tx CHAN ACT ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160 
(2291865->2291921)
<0011> lapd_core.c:920 Store content res. (dl=0xb66a83dc)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2292212->2292182)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2292208->2292246)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2292246->2292212)
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12917
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 
(dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160 
(2292814->2292870)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2293165->2293131)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2293178->2293221)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2293221->2293191)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2293200->2293239)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2293239->2293204)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2293404->2293447)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2293447->2293417)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2293417->2293455)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2293455->2293421)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2293443->2293486)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2293486->2293456)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2293469->2293507)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2293507->2293473)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2293677->2293720)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 
160 (2293720->2293681)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2293789->2293832)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 
160 (2293832->2293794)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 
(2293967->2294014)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2294014->2293984)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2293989->2294027)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2294027->2293993)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2294240->2294283)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2294283->2294253)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2294257->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2294296->2294262)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2294262->2294305)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 
160 (2294305->2294266)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 
(2294283->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2294331->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 480 vs 160 
(2294318->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2294335->2294374)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2294374->2294340)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2294409->2294452)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 
160 (2294452->2294413)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 
(2294929->2294976)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2294976->2294946)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2294951->2294989)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2294989->2294955)
<0000> rsl.c:689 (bts=0,trx=0,ts=2,ss=0) Sending Connection Failure: 
cause = 0x01
<0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm 
context. (sapi 0)
<0000> rsl.c:1433 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: 
cause = Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2295705->2295748)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2295752->2295718)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2295817->2295860)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2295869->2295835)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2295960->2296003)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
160 (2296003->2295973)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 
(2295978->2296016)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2296016->2295982)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
(2296030->2296073)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 
160 (2296077->2296043)
<0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure: 
cause = 0x01
<0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm 
context. (sapi 0)
<0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication: 
cause = Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=3,ss=0) Tx RF CHAN REL ACK


osmo-nitb -c config.cfg -C -m -P

<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: call re-establishment 
(ra=0x4f, neci=0x01, chreq_reason=0x02)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=2,ss=0) ChanModify for 
speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: answer to paging 
(ra=0x27, neci=0x01, chreq_reason=0x01)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=3,ss=0) ChanModify for 
speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: 
RELEASING state ACTIVE CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: 
RELEASING state ACTIVE CAUSE=0x01(Radio Link Failure)




versions of software:


osmo-nitb --version
OpenBSC version 1.0.0.14-98a2ba

~/Desktop/osmo/openbsc$ git log -1
commit 98a2ba4c57e95d2ce1e1e8147ea5a8d51788a191
Author: Vadim Yanitskiy <axilirator at gmail.com>
Date:?? Wed Jan 10 22:25:17 2018 +0600


((*))
 ? |
 ?/ \ OsmoBTS
OsmoBTS version 0.7.0.77-54be

~/Desktop/osmo/osmo-bts$ git log -1
commit 54be46949e93e07e9e57b706388ebb832e5fad0a
Author: Pau Espin Pedrol <pespin at sysmocom.de>
Date:?? Fri Feb 9 12:08:38 2018 +0100


osmo trx:

~/Desktop/osmo/osmo-trx$ git log -1
commit 77ce99ac6720896f504a0581a5c57b2929a13cef
Author: Pau Espin Pedrol <pespin at sysmocom.de>
Date:?? Mon Feb 5 13:05:06 2018 +0100


older osmo-bts-trx does actually work at least somewhat, but then voice 
transmission stops after 10-20 seconds, or sometimes even after 4 
minutes of talking, while . The older version is:

commit 9982b95069c58a3cb9b97bb6bc75932db81886ad
Author: Harald Welte <laforge at gnumonks.org>
Date:?? Tue Oct 24 18:42:30 2017 +0200

"OsmoBTS version 0.6.0.21-9982b-dirty"

I would, however, like to use a newer, preferably the master branch 
version from git.

Any help in dealing with this issue would be very greatly appreciated.





From n.kremeris at live.com  Wed Feb 14 17:40:23 2018
From: n.kremeris at live.com (Norbertas Kremeris)
Date: Wed, 14 Feb 2018 17:40:23 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection (using
 LimeSDR)
Message-ID: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>

Hello all,

I have run into some problems while building and running osmo-nitb, osmo-bts-trx and osmo-trx on Ubuntu 16.04. I am trying to create a self-contained gsm network box. I have successfully built libosmocore, libosmo-abis, libosmo-netif, libosmo-sccp, openbsc, osmo-bts and osmo-trx all from git sources, and i am also using linux call router. All make checks pass corrently without issues.

As for the SDR side, i am have the latest UHD, SoapySDR and SoapyUHD, and latest LimeSuite library for LimeSDR support.

SMS send/receive works correctly without any issues. Calling, however, works neither with osmo-nitb as standalone, neither with osmo-nitb with -m parameter + LCR. when trying to call, the receiving phone rings, but when trying to answer it randomly either gets stuck and does not answer, drops the call instantly or actually takes the call (and the elapsed seconds counter starts counting), but all you can hear is random noises coming both from the calling and from receiving phones, while the calling phone still shows that the call has not been answered, as in still calling.

this is the debug info from osmo-trx:

<0000> rsl.c:606 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
<0011> lapd_core.c:920 Store content res. (dl=0xb668cec8)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12405
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8 state LAPD_STATE_MF_EST)
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0000> rsl.c:606 (bts=0,trx=0,ts=3,ss=0) Tx CHAN ACT ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160 (2291865->2291921)
<0011> lapd_core.c:920 Store content res. (dl=0xb66a83dc)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2292212->2292182)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2292208->2292246)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2292246->2292212)
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12917
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160 (2292814->2292870)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2293165->2293131)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2293178->2293221)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2293221->2293191)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2293200->2293239)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2293239->2293204)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2293404->2293447)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2293447->2293417)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2293417->2293455)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2293455->2293421)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2293443->2293486)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2293486->2293456)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2293469->2293507)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2293507->2293473)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2293677->2293720)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160 (2293720->2293681)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2293789->2293832)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160 (2293832->2293794)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 (2293967->2294014)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2294014->2293984)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2293989->2294027)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2294027->2293993)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2294240->2294283)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2294283->2294253)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2294257->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2294296->2294262)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2294262->2294305)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160 (2294305->2294266)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 (2294283->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2294331->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 480 vs 160 (2294318->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2294335->2294374)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2294374->2294340)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2294409->2294452)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160 (2294452->2294413)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160 (2294929->2294976)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2294976->2294946)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2294951->2294989)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2294989->2294955)
<0000> rsl.c:689 (bts=0,trx=0,ts=2,ss=0) Sending Connection Failure: cause = 0x01
<0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm context. (sapi 0)
<0000> rsl.c:1433 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: cause = Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2295705->2295748)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2295752->2295718)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2295817->2295860)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2295869->2295835)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2295960->2296003)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2296003->2295973)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 (2295978->2296016)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2296016->2295982)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2296030->2296073)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160 (2296077->2296043)
<0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure: cause = 0x01
<0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm context. (sapi 0)
<0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication: cause = Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=3,ss=0) Tx RF CHAN REL ACK


osmo-nitb -c config.cfg -C -m -P

<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: call re-establishment (ra=0x4f, neci=0x01, chreq_reason=0x02)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=2,ss=0) ChanModify for speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: answer to paging (ra=0x27, neci=0x01, chreq_reason=0x01)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=3,ss=0) ChanModify for speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING state ACTIVE CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING state ACTIVE CAUSE=0x01(Radio Link Failure)




versions of software:


osmo-nitb --version
OpenBSC version 1.0.0.14-98a2ba

~/Desktop/osmo/openbsc$ git log -1
commit 98a2ba4c57e95d2ce1e1e8147ea5a8d51788a191
Author: Vadim Yanitskiy <axilirator at gmail.com><mailto:axilirator at gmail.com>
Date:   Wed Jan 10 22:25:17 2018 +0600


((*))
  |
 / \ OsmoBTS
OsmoBTS version 0.7.0.77-54be

~/Desktop/osmo/osmo-bts$ git log -1
commit 54be46949e93e07e9e57b706388ebb832e5fad0a
Author: Pau Espin Pedrol <pespin at sysmocom.de><mailto:pespin at sysmocom.de>
Date:   Fri Feb 9 12:08:38 2018 +0100


osmo trx:

~/Desktop/osmo/osmo-trx$ git log -1
commit 77ce99ac6720896f504a0581a5c57b2929a13cef
Author: Pau Espin Pedrol <pespin at sysmocom.de><mailto:pespin at sysmocom.de>
Date:   Mon Feb 5 13:05:06 2018 +0100


older osmo-bts-trx does actually work at least somewhat, but then voice transmission stops after 10-20 seconds, or sometimes even after 4 minutes of talking, while . The older version is:

commit 9982b95069c58a3cb9b97bb6bc75932db81886ad
Author: Harald Welte <laforge at gnumonks.org><mailto:laforge at gnumonks.org>
Date:   Tue Oct 24 18:42:30 2017 +0200

"OsmoBTS version 0.6.0.21-9982b-dirty"

I would, however, like to use a newer, preferably the master branch version from git.

Any help in dealing with this issue would be very greatly appreciated.




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

From djks74 at gmail.com  Thu Feb 15 16:23:47 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Thu, 15 Feb 2018 23:23:47 +0700
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
Message-ID: <CANWiJYixqyYttGjtXkQRFHdhwWvSftJRZvwkPfizgSrg-DZGbQ@mail.gmail.com>

Hi Norbertas,
Im wondering does your osmo-trx is running stable with LimeSDR? not having
glitch or stop in the middle or send timed out?
if yes, I assume it was osmo-trx still having problem.... im very curious
if you using latest osmo-trx and stable.

The other problem also your configuration. you need to give details.

DUO

On Thu, Feb 15, 2018 at 12:40 AM, Norbertas Kremeris <n.kremeris at live.com>
wrote:

> Hello all,
>
> I have run into some problems while building and running osmo-nitb,
> osmo-bts-trx and osmo-trx on Ubuntu 16.04. I am trying to create a
> self-contained gsm network box. I have successfully built libosmocore,
> libosmo-abis, libosmo-netif, libosmo-sccp, openbsc, osmo-bts and osmo-trx
> all from git sources, and i am also using linux call router. All make
> checks pass corrently without issues.
>
> As for the SDR side, i am have the latest UHD, SoapySDR and SoapyUHD, and
> latest LimeSuite library for LimeSDR support.
>
> SMS send/receive works correctly without any issues. Calling, however,
> works neither with osmo-nitb as standalone, neither with osmo-nitb with -m
> parameter + LCR. when trying to call, the receiving phone rings, but when
> trying to answer it randomly either gets stuck and does not answer, drops
> the call instantly or actually takes the call (and the elapsed seconds
> counter starts counting), but all you can hear is random noises coming both
> from the calling and from receiving phones, while the calling phone still
> shows that the call has not been answered, as in still calling.
>
> this is the debug info from osmo-trx:
>
> <0000> rsl.c:606 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
> <0011> lapd_core.c:920 Store content res. (dl=0xb668cec8)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0000> rsl.c:1639 CRCX does not specify a remote IP
> <0000> rsl.c:1646 CRCX does not specify a remote port
> <0000> rsl.c:1650 speech mode: 16
> <0000> rsl.c:1656 payload type: 3
> <0000> rsl.c:1636 connect_ip 16777343
> <0000> rsl.c:1643 connect_port 12405
> <0000> rsl.c:1650 speech mode: 0
> <0000> rsl.c:1656 payload type: 3
> <0009> pcu_sock.c:668 PCU socket not connected, dropping message
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8
> state LAPD_STATE_MF_EST)
> <0009> pcu_sock.c:668 PCU socket not connected, dropping message
> <0009> pcu_sock.c:668 PCU socket not connected, dropping message
> <0009> pcu_sock.c:668 PCU socket not connected, dropping message
> <0000> rsl.c:606 (bts=0,trx=0,ts=3,ss=0) Tx CHAN ACT ACK
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
> (2291865->2291921)
> <0011> lapd_core.c:920 Store content res. (dl=0xb66a83dc)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <0000> rsl.c:1639 CRCX does not specify a remote IP
> <0000> rsl.c:1646 CRCX does not specify a remote port
> <0000> rsl.c:1650 speech mode: 16
> <0000> rsl.c:1656 payload type: 3
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2292212->2292182)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2292208->2292246)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2292246->2292212)
> <0000> rsl.c:1636 connect_ip 16777343
> <0000> rsl.c:1643 connect_port 12917
> <0000> rsl.c:1650 speech mode: 0
> <0000> rsl.c:1656 payload type: 3
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc
> state LAPD_STATE_MF_EST)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
> (2292814->2292870)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2293165->2293131)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2293178->2293221)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2293221->2293191)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2293200->2293239)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2293239->2293204)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2293404->2293447)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2293447->2293417)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2293417->2293455)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2293455->2293421)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2293443->2293486)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2293486->2293456)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2293469->2293507)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2293507->2293473)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2293677->2293720)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
> (2293720->2293681)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2293789->2293832)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
> (2293832->2293794)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
> (2293967->2294014)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2294014->2293984)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2293989->2294027)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2294027->2293993)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2294240->2294283)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2294283->2294253)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2294257->2294296)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2294296->2294262)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2294262->2294305)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
> (2294305->2294266)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
> (2294283->2294331)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2294331->2294296)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 480 vs 160
> (2294318->2294331)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2294335->2294374)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2294374->2294340)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2294409->2294452)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
> (2294452->2294413)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
> (2294929->2294976)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2294976->2294946)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2294951->2294989)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2294989->2294955)
> <0000> rsl.c:689 (bts=0,trx=0,ts=2,ss=0) Sending Connection Failure: cause
> = 0x01
> <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm
> context. (sapi 0)
> <0000> rsl.c:1433 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication:
> cause = Normal event, unspecified
> <0000> rsl.c:580 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2295705->2295748)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2295752->2295718)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2295817->2295860)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2295869->2295835)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2295960->2296003)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
> (2296003->2295973)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> (2295978->2296016)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2296016->2295982)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
> (2296030->2296073)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
> (2296077->2296043)
> <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure: cause
> = 0x01
> <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm
> context. (sapi 0)
> <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication:
> cause = Normal event, unspecified
> <0000> rsl.c:580 (bts=0,trx=0,ts=3,ss=0) Tx RF CHAN REL ACK
>
>
> osmo-nitb -c config.cfg -C -m -P
>
> <0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: call re-establishment
> (ra=0x4f, neci=0x01, chreq_reason=0x02)
> <000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=2,ss=0) ChanModify for
> speech: SPEECH_V1 on channel TCH_F
> <0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: answer to paging (ra=0x27,
> neci=0x01, chreq_reason=0x01)
> <000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=3,ss=0) ChanModify for
> speech: SPEECH_V1 on channel TCH_F
> <0004> abis_rsl.c:1358 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING
> state ACTIVE CAUSE=0x01(Radio Link Failure)
> <0004> abis_rsl.c:1358 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING
> state ACTIVE CAUSE=0x01(Radio Link Failure)
>
>
>
>
> versions of software:
>
>
> osmo-nitb --version
> OpenBSC version 1.0.0.14-98a2ba
>
> ~/Desktop/osmo/openbsc$ git log -1
> commit 98a2ba4c57e95d2ce1e1e8147ea5a8d51788a191
> Author: Vadim Yanitskiy <axilirator at gmail.com> <axilirator at gmail.com>
> Date:   Wed Jan 10 22:25:17 2018 +0600
>
>
> ((*))
>   |
>  / \ OsmoBTS
> OsmoBTS version 0.7.0.77-54be
>
> ~/Desktop/osmo/osmo-bts$ git log -1
> commit 54be46949e93e07e9e57b706388ebb832e5fad0a
> Author: Pau Espin Pedrol <pespin at sysmocom.de> <pespin at sysmocom.de>
> Date:   Fri Feb 9 12:08:38 2018 +0100
>
>
> osmo trx:
>
> ~/Desktop/osmo/osmo-trx$ git log -1
> commit 77ce99ac6720896f504a0581a5c57b2929a13cef
> Author: Pau Espin Pedrol <pespin at sysmocom.de> <pespin at sysmocom.de>
> Date:   Mon Feb 5 13:05:06 2018 +0100
>
>
> older osmo-bts-trx does actually work at least somewhat, but then voice
> transmission stops after 10-20 seconds, or sometimes even after 4 minutes
> of talking, while . The older version is:
>
> commit 9982b95069c58a3cb9b97bb6bc75932db81886ad
> Author: Harald Welte <laforge at gnumonks.org> <laforge at gnumonks.org>
> Date:   Tue Oct 24 18:42:30 2017 +0200
>
> "OsmoBTS version 0.6.0.21-9982b-dirty"
>
> I would, however, like to use a newer, preferably the master branch
> version from git.
>
> Any help in dealing with this issue would be very greatly appreciated.
>
>
>
>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180215/c30e2f4c/attachment.htm>

From pespin at sysmocom.de  Fri Feb 16 13:14:04 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 16 Feb 2018 14:14:04 +0100
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
Message-ID: <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>

Hi,

I'm also experincing this issue while using limesdr, also using latest 
dependencies (soapysdr, limesuite, etc.) and latest osmo-trx.

The call is established correctly, but after a few seconds (or almost 
immediately) it is cancelled.

This explains that the call was closed:

 > <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure:
 > cause = 0x01
 > <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm
 > context. (sapi 0)
 > <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication:
 > cause = Normal event, unspecified

The RTP becoming out of sync most probably also explains too that a lot 
of packets are not being received correctly at l1sap layer:

> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
> (2295960->2296003)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
> 160 (2296003->2295973)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 


Reproducing a conversation relarted to this topic that I had with 
Harald, but unfortunately didn't have time to continue on it yet:

* Pau:
It seems it comes from osmo-bts l1sap_ph_data_ind with len(msgb)==0, 
indicating a bad frame. I can reproduce this every time I place a call 
between 2 MS with a limesdr.

* Harald:
well, it's not "a bad frame", but it's a lot of ongoing bad/lost
signaling blocks.

So first of all, this entire code path is not traversed for voice (TCH)
block, only for signalling (FACCH/SACCH) blocks. And then, there's the
's' counter implementing the radio link criterion. It is not formally
specified for the BTS side (see TS 45.008 Section 5.3), but we simply
implement what's specified for the MS side in TS 45.008 Section 5.2.

"S" is incremented for every good block by two, and decremented for
every bad block. And once it reaches a negative value, the
above-mentioned LINK FAILURE message is sent via RSL. See

So you must be loosing more than 66.6% of your total number of signaling
blocks to ever reach this point.

How do the measurement reports look like? Those are the most valuable
resource when debugging anything related to RF link issues.


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


From osmocom at lains.me  Fri Feb 16 20:07:28 2018
From: osmocom at lains.me (Osmocom Mailing List)
Date: Fri, 16 Feb 2018 20:07:28 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
Message-ID: <1518811648.11238.2@smtp.migadu.com>

Hi,

Can I see your configuration files? Particularly the OsmoNITB (OpenBSC) 
one.

Here's mine: 
https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50

Thanks,
Filipe La?ns <https://github.com/FFY00>

On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol <pespin at sysmocom.de> 
wrote:
> Hi,
> 
> I'm also experincing this issue while using limesdr, also using 
> latest dependencies (soapysdr, limesuite, etc.) and latest osmo-trx.
> 
> The call is established correctly, but after a few seconds (or almost 
> immediately) it is cancelled.
> 
> This explains that the call was closed:
> 
> > <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure:
> > cause = 0x01
> > <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without 
> LAPDm
> > context. (sapi 0)
> > <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete 
> indication:
> > cause = Normal event, unspecified
> 
> The RTP becoming out of sync most probably also explains too that a 
> lot of packets are not being received correctly at l1sap layer:
> 
>> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 
>> 160 (2295960->2296003)
>> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 
>> vs 160 (2296003->2295973)
>> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
> 
> Reproducing a conversation relarted to this topic that I had with 
> Harald, but unfortunately didn't have time to continue on it yet:
> 
> * Pau:
> It seems it comes from osmo-bts l1sap_ph_data_ind with len(msgb)==0, 
> indicating a bad frame. I can reproduce this every time I place a 
> call between 2 MS with a limesdr.
> 
> * Harald:
> well, it's not "a bad frame", but it's a lot of ongoing bad/lost
> signaling blocks.
> 
> So first of all, this entire code path is not traversed for voice 
> (TCH)
> block, only for signalling (FACCH/SACCH) blocks. And then, there's the
> 's' counter implementing the radio link criterion. It is not formally
> specified for the BTS side (see TS 45.008 Section 5.3), but we simply
> implement what's specified for the MS side in TS 45.008 Section 5.2.
> 
> "S" is incremented for every good block by two, and decremented for
> every bad block. And once it reaches a negative value, the
> above-mentioned LINK FAILURE message is sent via RSL. See
> 
> So you must be loosing more than 66.6% of your total number of 
> signaling
> blocks to ever reach this point.
> 
> How do the measurement reports look like? Those are the most valuable
> resource when debugging anything related to RF link issues.
> 
> 
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         
> http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte


Sent via Migadu.com, world's easiest email hosting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180216/bc562b09/attachment.htm>

From pespin at sysmocom.de  Mon Feb 19 10:20:43 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 19 Feb 2018 11:20:43 +0100
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <1518811648.11238.2@smtp.migadu.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
Message-ID: <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>

Hi,

I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to 
similar setup since OsmoNITB is being deprecated and most development 
work is happening in split componenets nowadays.

I attach my configs in case you want to start giving a try to the split 
components.

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myconfigs.tar.gz
Type: application/gzip
Size: 3490 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180219/04472fad/attachment.bin>

From djks74 at gmail.com  Mon Feb 19 11:31:21 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 19 Feb 2018 11:31:21 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
Message-ID: <CANWiJYhTSm5tmLA+Or8e6rs-2LyGdzhToiK4Fw5qWXUtwtxRtw@mail.gmail.com>

Dear Pespin,
please advise if this need run all? even for just voice service?

osmo-hlr -l hlr.db -c osmo-hlr.cfg
osmo-msc -c osmo-msc.cfg
osmo-mgw -c osmo-mgw-for-msc.cfg
osmo-mgw -c osmo-mgw-for-bsc.cfg
osmo-ggsn -c osmo-ggsn.cfg
osmo-sgsn -c osmo-sgsn.cfg
osmo-stp -c osmo-stp.cfg
osmo-bsc -c osmo-bsc.cfg
osmo-hnbgw -c osmo-hnbgw.cfg
osmo-bts-trx -c osmo-bts.cfg
osmo-pcu -c osmo-pcu.cfg

is it completed or I miss some to run?

we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw
for 2g voice only?

please advise. Thanks

DUO


On Mon, Feb 19, 2018 at 10:20 AM, Pau Espin Pedrol <pespin at sysmocom.de>
wrote:

> Hi,
>
> I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
> similar setup since OsmoNITB is being deprecated and most development work
> is happening in split componenets nowadays.
>
> I attach my configs in case you want to start giving a try to the split
> components.
>
>
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte
>



-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180219/a1a24504/attachment.htm>

From pespin at sysmocom.de  Mon Feb 19 11:46:52 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 19 Feb 2018 12:46:52 +0100
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <CANWiJYhTSm5tmLA+Or8e6rs-2LyGdzhToiK4Fw5qWXUtwtxRtw@mail.gmail.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <CANWiJYhTSm5tmLA+Or8e6rs-2LyGdzhToiK4Fw5qWXUtwtxRtw@mail.gmail.com>
Message-ID: <964d2bb1-cafe-6d55-69b8-072cd48fe43d@sysmocom.de>

> is it completed or I miss some to run?

Looks fine to me.

> 
> we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for 2g voice only?
> 

Indeed you can drop those if you don't want data access, and osmo-hnbgw 
if you are not using 3g.

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


From djks74 at gmail.com  Mon Feb 19 12:12:13 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 19 Feb 2018 12:12:13 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <964d2bb1-cafe-6d55-69b8-072cd48fe43d@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <CANWiJYhTSm5tmLA+Or8e6rs-2LyGdzhToiK4Fw5qWXUtwtxRtw@mail.gmail.com>
 <964d2bb1-cafe-6d55-69b8-072cd48fe43d@sysmocom.de>
Message-ID: <CANWiJYhnu=rDTGf0eZrqHm9eZrk4Lf_DGJM9x7=VpWxK1nTKZw@mail.gmail.com>

allright!
will try your config tonight for the voice. :)

thanks Pespin.

DUO

On Feb 19, 2018 6:46 PM, "Pau Espin Pedrol" <pespin at sysmocom.de> wrote:

> is it completed or I miss some to run?
>>
>
> Looks fine to me.
>
>
>> we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for
>> 2g voice only?
>>
>>
> Indeed you can drop those if you don't want data access, and osmo-hnbgw if
> you are not using 3g.
>
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180219/7b2de2cd/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Feb 19 13:40:00 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 19 Feb 2018 14:40:00 +0100
Subject: msc_vlr_tests patches
In-Reply-To: <ffabb3bc-eef9-014f-a264-5e9a4714f6ad@sysmocom.de>
References: <20180212152344.GA13209@my.box>
 <ffabb3bc-eef9-014f-a264-5e9a4714f6ad@sysmocom.de>
Message-ID: <20180219133959.k4de4lg5nnleiuvx@ass40.sysmocom.de>

On Tue, Feb 13, 2018 at 02:17:17PM +0100, Max wrote:
> > The reason why I wanted that number output only in verbose mode is, I don't
> > want to adjust unrelated *.err output when adding a test in any position that
> > is not the last.
> 
> Curious. When would we want to do that? I assumed tests are independent of
> each other. That's not the case?

The tests were independent, but since they now print their number in the
expected output, they no longer are. To illustrate, some pseudocode:

Before:

  ===== test_no_auten...
  ===== test_no_auten_imei...

Now:

  ===== [1] test_no_auten...
  ===== [2] test_no_auten_imei...

If I now add a test

  ===== [1] test_no_auten...
  ===== [2] test_no_auten_tmsi...  <-- new
  ===== [3] test_no_auten_imei...

leads to "Test failed" because the number changed:

    ===== [1] test_no_auten...
    ===== [2] test_no_auten_tmsi...
  - ===== [2] test_no_auten_imei...
  + ===== [3] test_no_auten_imei...

All subsequent tests' output needed adjustment.

This happened a lot during early development, because I wanted semantic
order instead of only adding in the end, hence I had those indexes output
only when -v was passed so they don't mess up expected output.

> The idea is to make IMSI into actual parameter so it would be easy to
> introduce tests with different edge cases - shorter-than-normal,
> longer-than-normal IMSI etc. It have not materialized (yet?) though due to
> way too many hardcoded hex strings in tests.

I see that idea, but it goes against how these tests were conceived: they
are on purpose passing in raw hex streams of data. It has disadvantages
but also guarantees to see exactly what is being tested in all clarity.

The disadvantage is that you can't parameterize the hex strings easily.
But I on purpose didn't want to incorporate our encoding functions and use
structs. One reason is practical: I can just copy paste PDU data from a
pcap of an actual real test, and from that point on I am testing exactly
what the phone sent. Apart from that, I also generally discourage
parameterizing tests (I do in few cases to spare some heavy code
duplication, but try to minimize or avoid altogether). The reason is: when
everything from the test side is hardcoded and actual duplicated code,
each test is ultimately independent and terminally clear. After all it's
not production code that we need to maintain in the sense of API, their
purpose is to model a rock hard situation that should be easy to step
through if a test fails, without figuring out which parameters were passed
and which code paths were taken.

TTCN3 is more elegant in the sense that it "adds ways to compose the PDUs
more flexibly"-squared. Notably it also employs its own and independent
protocol definitions and also doesn't use our own encoding functions.

An advantage of the msc_vlr_tests is that they are blazingly fast and
independent of external dependencies etc., so they tell you right away
during development what you've changed.

So those are the guidelines the msc_vlr_tests were based on. If I were to
test longer and shorter IMSIs as msc_vlr_test, I would simply add another
test, copy-pasting an existing one and hand editing the IMSI. May sound
crazy, but for testing code my opinion is that this is the actual way to
do it, and it is consciously kind of opposite of API development. Doing
that in ttcn-3 is a good alternative, but parameterizing *all* of the
msc_vlr_tests clearly isn't.

(I already pointed Max at a test that would be convenient to adjust, last
week in person: test_lu_unknown_tmsi() does an IMSI identity request, and
one only needs to change the IMSI in the reply.)

> > 3) you moved gsm_network creation into a separate function, but that function
> > is still called only once. So it's just cosmetic, or was there another purpose?
> > 
> See above.

See where? Was there another purpose or not? AFAICT gsm_network creation
is still and probably will always be called only once from the main()
function.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180219/83ec6be0/attachment.bin>

From n.kremeris at live.com  Mon Feb 19 07:57:11 2018
From: n.kremeris at live.com (Norbertas Kremeris)
Date: Mon, 19 Feb 2018 07:57:11 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <1518811648.11238.2@smtp.migadu.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
Message-ID: <DB6PR0902MB19263362633124CCC31409D8FFC80@DB6PR0902MB1926.eurprd09.prod.outlook.com>

Hello again,

Thanks for the reply. Here is my nitb configuration:

e1_input
 e1_line 0 driver ipa
 e1_line 0 port 0
network
 network country code 1
 mobile network code 1
 short name LimeSDR
 long name LimeSDR
 auth policy accept-all
 location updating reject cause 13
 encryption a5 0
 neci 1
 paging any use tch 0
 rrlp mode none
 mm info 1
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999
 timer t3101 10
! timer t3103 0
! timer t3105 0
! timer t3107 0
 timer t3109 4
! timer t3111 0
 timer t3113 60
! timer t3115 0
! timer t3117 0
! timer t3119 0
 timer t3122 10
! timer t3141 0
 dtx-used 0
 subscriber-keep-in-ram 0
 bts 0
  type sysmobts
  band DCS1800
  cell_identity 0
  location_area_code 2
  training_sequence_code 7
!  base_station_id_code 63
  ms max power 23
  cell reselection hysteresis 4
  rxlev access min 0
  periodic location update 30
!  radio-link-timeout 32
  channel allocator ascending
  rach tx integer 9
  rach max transmission 7
  channel-descrption attach 1
  channel-descrption bs-pa-mfrms 5
  channel-descrption bs-ag-blks-res 1
  ip.access unit_id 1801 0
  oml ip.access stream_id 255 line 0
  neighbor-list mode automatic
!  codec-support fr efr afs
!  amr tch-f modes 2
!  amr tch-f start-mode 1
!  amr tch-h modes 2
!  amr tch-h start-mode 1
  gprs mode none
  trx 0
   rf_locked 0
   arfcn 525
   nominal power 23
   max_power_red 0
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
mncc-int
 default-codec tch-f amr
 default-codec tch-h amr


And here is my osmo-bts-trx configuration:

phy 0
 instance 0
  osmotrx rx-gain 1
 osmotrx ip local 127.0.0.1
 osmotrx ip remote 127.0.0.1
bts 0
 band DCS1800
 ipa unit-id 1801 0
 oml remote-ip 127.0.0.1
 gsmtap-sapi ccch
 gsmtap-sapi pdtch
 trx 0
  phy 0 instance 0

I do however doubt that the LimeSDR is at fault for the voice calls failing, as on an older osmo-bts-trx ver. 0.6.0.21-9982b, I get the same RTP errors (<0007> l1sap.c:96 RTP clock out of sync with lower layer: 0 vs 160 (456369->456369)) but voice calls do work (at least somewhat)




On 2018.02.16 22:07, Osmocom Mailing List wrote:
Hi,

Can I see your configuration files? Particularly the OsmoNITB (OpenBSC) one.

Here's mine: https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50

Thanks,
Filipe La?ns <https://github.com/FFY00>

On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol <pespin at sysmocom.de><mailto:pespin at sysmocom.de> wrote:
Hi, I'm also experincing this issue while using limesdr, also using latest dependencies (soapysdr, limesuite, etc.) and latest osmo-trx. The call is established correctly, but after a few seconds (or almost immediately) it is cancelled. This explains that the call was closed: > <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure: > cause = 0x01 > <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm > context. (sapi 0) > <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication: > cause = Normal event, unspecified The RTP becoming out of sync most probably also explains too that a lot of packets are not being received correctly at l1sap layer:
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 (2295960->2296003) <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160 (2296003->2295973) <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
Reproducing a conversation relarted to this topic that I had with Harald, but unfortunately didn't have time to continue on it yet: * Pau: It seems it comes from osmo-bts l1sap_ph_data_ind with len(msgb)==0, indicating a bad frame. I can reproduce this every time I place a call between 2 MS with a limesdr. * Harald: well, it's not "a bad frame", but it's a lot of ongoing bad/lost signaling blocks. So first of all, this entire code path is not traversed for voice (TCH) block, only for signalling (FACCH/SACCH) blocks. And then, there's the 's' counter implementing the radio link criterion. It is not formally specified for the BTS side (see TS 45.008 Section 5.3), but we simply implement what's specified for the MS side in TS 45.008 Section 5.2. "S" is incremented for every good block by two, and decremented for every bad block. And once it reaches a negative value, the above-mentioned LINK FAILURE message is sent via RSL. See So you must be loosing more than 66.6% of your total number of signaling blocks to ever reach this point. How do the measurement reports look like? Those are the most valuable resource when debugging anything related to RF link issues.
--
- Pau Espin Pedrol <pespin at sysmocom.de<mailto:pespin at sysmocom.de>> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Sent via Migadu.com, world's easiest email hosting<https://migadu.com?s=sent_via>

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

From djks74 at gmail.com  Tue Feb 20 02:35:44 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 20 Feb 2018 02:35:44 +0000
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <CANWiJYhnu=rDTGf0eZrqHm9eZrk4Lf_DGJM9x7=VpWxK1nTKZw@mail.gmail.com>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <CANWiJYhTSm5tmLA+Or8e6rs-2LyGdzhToiK4Fw5qWXUtwtxRtw@mail.gmail.com>
 <964d2bb1-cafe-6d55-69b8-072cd48fe43d@sysmocom.de>
 <CANWiJYhnu=rDTGf0eZrqHm9eZrk4Lf_DGJM9x7=VpWxK1nTKZw@mail.gmail.com>
Message-ID: <CANWiJYi_N_WtBr1KckXtEF0OWE_UU20SpSx_Faa9SW2D=-JbhA@mail.gmail.com>

Dear Pespin.
Still no voice on my side using your configuration.  :-(

best,
Sandi

On Mon, Feb 19, 2018 at 12:12 PM, Sandi Suhendro <djks74 at gmail.com> wrote:

> allright!
> will try your config tonight for the voice. :)
>
> thanks Pespin.
>
> DUO
>
> On Feb 19, 2018 6:46 PM, "Pau Espin Pedrol" <pespin at sysmocom.de> wrote:
>
>> is it completed or I miss some to run?
>>>
>>
>> Looks fine to me.
>>
>>
>>> we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for
>>> 2g voice only?
>>>
>>>
>> Indeed you can drop those if you don't want data access, and osmo-hnbgw
>> if you are not using 3g.
>>
>> --
>> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
>> =======================================================================
>> * sysmocom - systems for mobile communications GmbH
>> * Alt-Moabit 93
>> * 10559 Berlin, Germany
>> * Sitz / Registered office: Berlin, HRB 134158 B
>> * Geschaeftsfuehrer / Managing Director: Harald Welte
>>
>


-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180220/e1b36038/attachment.htm>

From jenkins at lists.osmocom.org  Wed Feb 21 02:28:49 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Wed, 21 Feb 2018 02:28:49 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #20
Message-ID: <1623913169.920.1519180129834.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/20/display/redirect>

------------------------------------------
[...truncated 1.05 MB...]
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for UHD... no
checking for UHD... yes
checking whether C compiler accepts -msse3... yes
checking whether C compiler accepts -msse4.1... yes
checking whether gcc has __builtin_cpu_supports built-in... yes
checking for LIBUSB... yes
checking for FFTWF... yes
checking boost/config.hpp usability... yes
checking boost/config.hpp presence... yes
checking for boost/config.hpp... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating CommonLibs/Makefile
config.status: creating GSM/Makefile
config.status: creating Transceiver52M/Makefile
config.status: creating Transceiver52M/arm/Makefile
config.status: creating Transceiver52M/x86/Makefile
config.status: creating tests/Makefile
config.status: creating tests/CommonLibs/Makefile
config.status: creating tests/Transceiver52M/Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 6
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Making all in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
  CXX      BitVector.lo
  CXX      Threads.lo
  CXX      Timeval.lo
  CXX      Logger.lo
  CXX      Sockets.lo
  CXX      LinkedLists.lo
  CXXLD    libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making all in GSM
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
  CXX      GSMCommon.lo
  CXXLD    libGSM.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making all in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in arm
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making all in x86
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
  CC       convert.lo
  CC       convolve.lo
  CC       libarch_sse_3_la-convolve_sse_3.lo
  CC       libarch_sse_3_la-convert_sse_3.lo
  CC       ../common/convolve_base.lo
  CC       libarch_sse_4_1_la-convert_sse_4_1.lo
  CC       ../common/convert_base.lo
  CCLD     libarch_sse_4_1.la
  CCLD     libarch_sse_3.la
ar: `u' modifier ignored since `D' is the default (see `U')
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
  CXX      radioInterface.lo
  CXX      radioVector.lo
  CXX      radioClock.lo
  CXX      signalVector.lo
  CXX      sigProcLib.lo
  CXX      radioBuffer.lo
  CXX      Transceiver.lo
  CXX      ChannelizerBase.lo
  CXX      Channelizer.lo
  CXX      Synthesis.lo
  CC       common/fft.lo
  CXX      Resampler.lo
  CXX      radioInterfaceResamp.lo
  CXX      radioInterfaceMulti.lo
  CXX      UHDDevice.lo
  CXX      osmo-trx.o
  CXXLD    libtransceiver.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CXXLD    osmo-trx
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in tests
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making all in CommonLibs
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
  CXX      BitVectorTest.o
  CXX      InterthreadTest.o
  CXX      VectorTest.o
  CXX      PRBSTest.o
  CXX      SocketsTest.o
  CXX      TimevalTest.o
  CXX      LogTest.o
  CXXLD    BitVectorTest
  CXXLD    VectorTest
  CXXLD    SocketsTest
  CXXLD    TimevalTest
  CXXLD    PRBSTest
  CXXLD    InterthreadTest
  CXXLD    LogTest
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making all in Transceiver52M
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
  CC       convolve_test-convolve_test.o
  CCLD     convolve_test
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ make install
Making install in CommonLibs
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making install in GSM
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making install in Transceiver52M
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in arm
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making install in x86
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
  /bin/bash /home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/libtool   --mode=install /usr/bin/install -c osmo-trx '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
libtool: install: /usr/bin/install -c osmo-trx /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in tests
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making install in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making install in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ popd
~/osmo-ci/coverity/source-Osmocom
Emitted 2324 C/C++ compilation units (100%) successfully

2324 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
+ cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom
+ rm -f Osmocom.tgz
+ tar czf Osmocom.tgz cov-int
+ set +x
curl \
 --form token="$token" \
 --form email=holger at freyther.de --form file=@Osmocom.tgz \
 --form version=Version --form description=AutoUpload \
 https://scan.coverity.com/builds?project=Osmocom
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com'
Build step 'Execute shell' marked build as failure


From rafael at riseup.net  Wed Feb 21 04:43:57 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Wed, 21 Feb 2018 01:43:57 -0300
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
Message-ID: <a526e69c-030d-9315-1091-7d8043aba1ab@riseup.net>

Thanks Pau!

I'm trying to use the configs you sent with osmo stack installed in my
PC, and the BTS running the a NuRAN LC15. From the osmo-bsc log, I get:

20180221013938451 DLINP <0013> input/ipa.c:265 accept()ed new link from
10.42.123.100 to port 3002
20180221013938451 DLINP <0013> bts_ipaccess_nanobts.c:416 Unable to find
BTS configuration for  1000/0/0, disconnecting
20180221013938451 DLINP <0013> input/ipaccess.c:161 Unable to set signal
link, closing socket.

Any idea what am I doing wrong?

Rafael Diniz

On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
> Hi,
> 
> I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
> similar setup since OsmoNITB is being deprecated and most development
> work is happening in split componenets nowadays.
> 
> I attach my configs in case you want to start giving a try to the split
> components.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180221/e3fe1a11/attachment.bin>

From djks74 at gmail.com  Wed Feb 21 04:51:50 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 21 Feb 2018 11:51:50 +0700
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
 (using LimeSDR)
In-Reply-To: <a526e69c-030d-9315-1091-7d8043aba1ab@riseup.net>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <a526e69c-030d-9315-1091-7d8043aba1ab@riseup.net>
Message-ID: <CANWiJYjOpL_dsOn=41psXWk0cXUDcAn3oY5bx2UjK6zsfSD0yg@mail.gmail.com>

Try set the ip you see is same in config, example as default is 127.0.0.1.

DUO

On Feb 21, 2018 11:47 AM, "Rafael Diniz" <rafael at riseup.net> wrote:

> Thanks Pau!
>
> I'm trying to use the configs you sent with osmo stack installed in my
> PC, and the BTS running the a NuRAN LC15. From the osmo-bsc log, I get:
>
> 20180221013938451 DLINP <0013> input/ipa.c:265 accept()ed new link from
> 10.42.123.100 to port 3002
> 20180221013938451 DLINP <0013> bts_ipaccess_nanobts.c:416 Unable to find
> BTS configuration for  1000/0/0, disconnecting
> 20180221013938451 DLINP <0013> input/ipaccess.c:161 Unable to set signal
> link, closing socket.
>
> Any idea what am I doing wrong?
>
> Rafael Diniz
>
> On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
> > Hi,
> >
> > I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
> > similar setup since OsmoNITB is being deprecated and most development
> > work is happening in split componenets nowadays.
> >
> > I attach my configs in case you want to start giving a try to the split
> > components.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180221/ebc2b10d/attachment.htm>

From rafael at riseup.net  Wed Feb 21 06:36:27 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Wed, 21 Feb 2018 03:36:27 -0300
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
In-Reply-To: <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
Message-ID: <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>

I advanced here in putting the new split stack working. By mistake I put
different ip.access unit_id between bts and bsc... sorry my last email.

But still no luck.

Osmo-BSC gives me:
        PART(T=Cause,L=4,D=00000300)
20180221033117954 DLSCCP <001e> sccp_scoc.c:1548 Received CO:RELRE for
local reference 1
20180221033117954 DLSCCP <001e> sccp_scoc.c:1581
SCCP-SCOC(1)[0x55decef19a70]{ACTIVE}: Received Event RCOC-RELEASED.ind
20180221033117954 DLSCCP <001e> sccp_user.c:156 Delivering
N-DISCONNECT.indication to SCCP User 'msc-0'
20180221033117954 DMSC <0008> osmo_bsc_sigtran.c:223 N-DISCONNECT.ind(1,
cause=768)
20180221033117954 DMSC <0008> osmo_bsc_sigtran.c:364 sccp connection
(id=1) not cleared (gsm subscriber connection still active) --
forcefully clearing it now!
20180221033117954 DMSC <0008> a_reset.c:175
A-RESET(msc-0)[0x55decef17b30]{CONN}: Received Event 1
20180221033117954 DLSS7 <001d> sccp_scrc.c:391
sccp_scrc_rx_scoc_conn_msg:  HDR=(CO:RELCO,V=0,LEN=0),
        PART(T=Routing Context,L=4,D=00000000),
        PART(T=Destination Reference,L=4,D=00000002),
        PART(T=Source Reference,L=4,D=00000001)
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:278
m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for
dpc=185=0.23.1: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-msc-0 proto=m3ua
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is
M3UA for dpc=185=0.23.1
20180221033117954 DLSS7 <001d> m3ua.c:507
XUA_AS(as-clnt-msc-0)[0x55decef16d80]{AS_ACTIVE}: Received Event
AS-TRANSFER.req
20180221033117954 DLSCCP <001e> sccp_scoc.c:972
SCCP-SCOC(1)[0x55decef19a70]{ACTIVE}: state_chg to IDLE
20180221033117954 DLSCCP <001e> sccp_scoc.c:420
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Terminating (cause =
OSMO_FSM_TERM_REQUEST)
20180221033117954 DLSCCP <001e> sccp_scoc.c:420
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Freeing instance
20180221033117954 DLSCCP <001e> fsm.c:344
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Deallocated
20180221033117954 DLINP <0013> stream.c:279 connected write
20180221033117954 DLINP <0013> stream.c:204 sending data
20180221033117954 DLINP <0013> stream.c:279 connected write
20180221033117954 DLINP <0013> stream.c:204 sending data
20180221033118184 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 DATA INDICATION
20180221033118184 DRSL <0004> bsc_api.c:803 Got data in non active
state(RELEASE REQUESTED), discarding.
20180221033118184 DLINP <0013> input/ipaccess.c:285 Bad signalling
message, sign_link returned error: Operation not permitted.
20180221033118419 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 DATA INDICATION
20180221033118419 DRSL <0004> bsc_api.c:803 Got data in non active
state(RELEASE REQUESTED), discarding.
20180221033118419 DLINP <0013> input/ipaccess.c:285 Bad signalling
message, sign_link returned error: Operation not permitted.
20180221033118654 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 RELEASE INDICATION
20180221033120655 DRSL <0004> abis_rsl.c:1764 (bts=0,trx=0,ts=0,ss=1)
T3111 expired: releasing RF Channel
20180221033120656 DRSL <0004> abis_rsl.c:872 (bts=0,trx=0,ts=0,ss=1) RF
Channel Release
20180221033120657 DRSL <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=1) RF
CHANNEL RELEASE ACK
20180221033120657 DRSL <0004> abis_rsl.c:85 (bts=0,trx=0,ts=0,ss=1)
state RELEASE REQUESTED -> NONE

Thanks!
Rafael Diniz

On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
> Hi,
> 
> I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
> similar setup since OsmoNITB is being deprecated and most development
> work is happening in split componenets nowadays.
> 
> I attach my configs in case you want to start giving a try to the split
> components.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180221/43b50dc1/attachment.bin>

From pespin at sysmocom.de  Wed Feb 21 10:23:28 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 21 Feb 2018 11:23:28 +0100
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
In-Reply-To: <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>
Message-ID: <76be64c9-ba2b-7fc5-e329-2057ff39031e@sysmocom.de>

Hi Rafael,

I have no idea on what's wrong unless you provide more information on 
what's exactly not working.

To give you some hints: In my configs, 192.168.30.1 is my laptop 
(running all the core network) and 192.168.30.100 is my BTS (which 
depending on the BTS is also in my laptop, so I assign 2 IPs to one 
iface for simplicity of my configs).

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


From rafael at riseup.net  Wed Feb 21 13:09:14 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Wed, 21 Feb 2018 10:09:14 -0300
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
In-Reply-To: <76be64c9-ba2b-7fc5-e329-2057ff39031e@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>
 <76be64c9-ba2b-7fc5-e329-2057ff39031e@sysmocom.de>
Message-ID: <219e7718-2135-e1c0-7391-cfe84c35d769@riseup.net>

Hi Pau,
Can I use loopback addresses or should I use local network addresses?

Today I'll debug more the issue, but as soon as I make it work, I
publish my config files too.. I'm pretty certain I'm doing something wrong.

Btw, osmo-bsc_mgcp still need to be called together with current git
osmo-msc and osmo-mgw, right?

Thanks a lot, your config files are really helping.
Rafael Diniz


On 02/21/2018 07:23 AM, Pau Espin Pedrol wrote:
> Hi Rafael,
> 
> I have no idea on what's wrong unless you provide more information on
> what's exactly not working.
> 
> To give you some hints: In my configs, 192.168.30.1 is my laptop
> (running all the core network) and 192.168.30.100 is my BTS (which
> depending on the BTS is also in my laptop, so I assign 2 IPs to one
> iface for simplicity of my configs).
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180221/e3668b72/attachment.bin>

From pespin at sysmocom.de  Wed Feb 21 15:36:44 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 21 Feb 2018 16:36:44 +0100
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
In-Reply-To: <219e7718-2135-e1c0-7391-cfe84c35d769@riseup.net>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>
 <76be64c9-ba2b-7fc5-e329-2057ff39031e@sysmocom.de>
 <219e7718-2135-e1c0-7391-cfe84c35d769@riseup.net>
Message-ID: <8b120a9f-9a8c-86e8-f552-e8bd10294b6b@sysmocom.de>



On 21/02/18 14:09, Rafael Diniz wrote:
> Hi Pau,
> Can I use loopback addresses or should I use local network addresses?
> 

Unless I'm forgetting some detail, it shuld be fine to run everything 
with loopback addresses.

> Btw, osmo-bsc_mgcp still need to be called together with current git
> osmo-msc and osmo-mgw, right?

As far as I know latest osmo-msc already requires osmo-mgw.


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


From jenkins at lists.osmocom.org  Thu Feb 22 02:29:04 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Thu, 22 Feb 2018 02:29:04 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #21
In-Reply-To: <1623913169.920.1519180129834.JavaMail.jenkins@jenkins.osmocom.org>
References: <1623913169.920.1519180129834.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <739766168.977.1519266544849.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/21/display/redirect>

------------------------------------------
[...truncated 1.10 MB...]
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking for UHD... no
checking for UHD... yes
checking whether C compiler accepts -msse3... yes
checking whether C compiler accepts -msse4.1... yes
checking whether gcc has __builtin_cpu_supports built-in... yes
checking for LIBUSB... yes
checking for FFTWF... yes
checking boost/config.hpp usability... yes
checking boost/config.hpp presence... yes
checking for boost/config.hpp... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating CommonLibs/Makefile
config.status: creating GSM/Makefile
config.status: creating Transceiver52M/Makefile
config.status: creating Transceiver52M/arm/Makefile
config.status: creating Transceiver52M/x86/Makefile
config.status: creating tests/Makefile
config.status: creating tests/CommonLibs/Makefile
config.status: creating tests/Transceiver52M/Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 6
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Making all in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
  CXX      BitVector.lo
  CXX      Sockets.lo
  CXX      LinkedLists.lo
  CXX      Timeval.lo
  CXX      Threads.lo
  CXX      Logger.lo
  CXXLD    libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making all in GSM
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
  CXX      GSMCommon.lo
  CXXLD    libGSM.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making all in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in arm
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making all in x86
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
  CC       convolve.lo
  CC       libarch_sse_3_la-convert_sse_3.lo
  CC       libarch_sse_3_la-convolve_sse_3.lo
  CC       convert.lo
  CC       libarch_sse_4_1_la-convert_sse_4_1.lo
  CC       ../common/convolve_base.lo
  CC       ../common/convert_base.lo
  CCLD     libarch_sse_4_1.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch_sse_3.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
  CXX      radioVector.lo
  CXX      radioBuffer.lo
  CXX      radioInterface.lo
  CXX      signalVector.lo
  CXX      sigProcLib.lo
  CXX      radioClock.lo
  CXX      Transceiver.lo
  CXX      ChannelizerBase.lo
  CXX      Channelizer.lo
  CXX      Synthesis.lo
  CC       common/fft.lo
  CXX      Resampler.lo
  CXX      radioInterfaceResamp.lo
  CXX      radioInterfaceMulti.lo
  CXX      UHDDevice.lo
  CXX      osmo-trx.o
  CXXLD    libtransceiver.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CXXLD    osmo-trx
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in tests
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making all in CommonLibs
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
  CXX      BitVectorTest.o
  CXX      PRBSTest.o
  CXX      InterthreadTest.o
  CXX      VectorTest.o
  CXX      SocketsTest.o
  CXX      TimevalTest.o
  CXX      LogTest.o
  CXXLD    PRBSTest
  CXXLD    TimevalTest
  CXXLD    SocketsTest
  CXXLD    VectorTest
  CXXLD    BitVectorTest
  CXXLD    InterthreadTest
  CXXLD    LogTest
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making all in Transceiver52M
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
  CC       convolve_test-convolve_test.o
  CCLD     convolve_test
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ make install
Making install in CommonLibs
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making install in GSM
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making install in Transceiver52M
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in arm
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making install in x86
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
  /bin/bash /home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/libtool   --mode=install /usr/bin/install -c osmo-trx '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
libtool: install: /usr/bin/install -c osmo-trx /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in tests
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making install in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making install in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ popd
~/osmo-ci/coverity/source-Osmocom
Emitted 2324 C/C++ compilation units (100%) successfully

2324 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
+ cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom
+ rm -f Osmocom.tgz
+ tar czf Osmocom.tgz cov-int
+ set +x
curl \
 --form token="$token" \
 --form email=holger at freyther.de --form file=@Osmocom.tgz \
 --form version=Version --form description=AutoUpload \
 https://scan.coverity.com/builds?project=Osmocom
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com'
Build step 'Execute shell' marked build as failure


From nhofmeyr at sysmocom.de  Thu Feb 22 23:58:15 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 23 Feb 2018 00:58:15 +0100
Subject: fairwaves HO patches
In-Reply-To: <CA+QHiD-iLf_fiYu3SwommvsmTb_B+5rnE+VUGGD6FFNvSxfd_Q@mail.gmail.com>
References: <gerrit.1486741011493.Iad3cf545b2f7e16276466cc37dd7a1e7858467e5@gerrit.osmocom.org>
 <20180115214505.GC14510@my.box>
 <CA+QHiD-iLf_fiYu3SwommvsmTb_B+5rnE+VUGGD6FFNvSxfd_Q@mail.gmail.com>
Message-ID: <20180222235815.GA702@my.box>

On Tue, Feb 13, 2018 at 10:01:11PM +0300, Ivan Kluchnikov wrote:
[...]
> For tests, I called bsc_handover_start function from different parts of the
> code and for different states of the call and checked media and signalling
> after and during HO procedure.

Nice idea :)

> So one of the main improvement which should be implemented is an automated
> test suite for HO procedure which will cover all stages of the call.

Our TTCN-3 test suite is probably a good place to put this.
We also have the osmo-gsm-tester, to verify with real hardware.

> > >       gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref);
> > >
> > > +     new_lchan->conn->in_handover = 1;
> > > +
> >
> > In current osmo-bsc master, we already set conn->ho_lchan before sending
> > out
> > the chan activation request. I'd actually assume setting the flag only now,
> > after the activ ack, is a bit too late?
> 
> 
> I set it right after gsm48_send_ho_cmd, because sending of HO CMD is the
> actual start of handover procedure (as I understand specs).

Ah, from the context of the original lchan, starting to be in handover probably
is at this point. But from the conn's perspective I'd like to think of it
starting to be in handover the moment we've decided that we want it to
handover, i.e. from bsc_handover_start(), where we initially choose the lchan
to handover to and start to chan-activ that. So ok, it's just a matter of
perspective.

> > >       /* start T3103.  We can continue either with T3103 expiration,
> > >        * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */
> > >       ho->T3103.cb = ho_T3103_cb;
> > > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan
> > *new_lchan)
> > >       osmo_timer_schedule(&ho->T3103, 10, 0);
> > >
> > >       /* create a RTP connection */
> > > -     if (is_ipaccess_bts(new_lchan->ts->trx->bts))
> > > +     if (is_ipaccess_bts(new_lchan->ts->trx->bts) &&
> > > +                                     new_lchan->tch_mode !=
> > GSM48_CMODE_SIGN)
> > >               rsl_ipacc_crcx(new_lchan);
> >
> > Please explain ... what case / behavior is this fixing?
> > Do we ever see CMODE_SIGN handovers?
> > Would we also need to check for GSM48_CMODE_DATA_*?
> >
> 
> Yes, handover can be initiated in any mode of lchan and we saw handovers
> for lchans in GSM48_CMODE_SIGN mode.
> So I think we should be able to cover this case because I didn't find any
> mention in the specs that this case is prohibited for HO.
> I don't know if HO is allowed for CSD (GSM48_CMODE_DATA_*), it should be
> checked.
> But if it is prohibited for CSD, I think we should check and block it on
> the stage of bsc_handover_start or earlier.

So, what is CMODE_DATA, is it for PDCH / GPRS data?

As far as osmo-bsc is concerned, a timeslot used for data appears as "not in
use", osmo-bts leaves operation of PDCH to the pcu. I don't think receiving a
handover for a data ts is possible, because they are no lchans.

Or is CMODE_DATA something I don't know about yet? :)


[...]

Thanks for the remaining explanations, which help a lot to clarify.

FYI, one of my next tasks is to implement the inter-BSC handover part for
osmo-bsc, and it's likely that the MSC part for inter-BSC handover will follow
or go along with it; for which your patches and comments will be very helpful.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180223/d4909fb7/attachment.bin>

From jenkins at lists.osmocom.org  Fri Feb 23 02:29:09 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Fri, 23 Feb 2018 02:29:09 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #22
In-Reply-To: <739766168.977.1519266544849.JavaMail.jenkins@jenkins.osmocom.org>
References: <739766168.977.1519266544849.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <112303554.1039.1519352949710.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/22/display/redirect>

------------------------------------------
[...truncated 1.10 MB...]
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking for LIBOSMOCORE... yes
checking for UHD... no
checking for UHD... yes
checking whether C compiler accepts -msse3... yes
checking whether C compiler accepts -msse4.1... yes
checking whether gcc has __builtin_cpu_supports built-in... yes
checking for LIBUSB... yes
checking for FFTWF... yes
checking boost/config.hpp usability... yes
checking boost/config.hpp presence... yes
checking for boost/config.hpp... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating CommonLibs/Makefile
config.status: creating GSM/Makefile
config.status: creating Transceiver52M/Makefile
config.status: creating Transceiver52M/arm/Makefile
config.status: creating Transceiver52M/x86/Makefile
config.status: creating tests/Makefile
config.status: creating tests/CommonLibs/Makefile
config.status: creating tests/Transceiver52M/Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 6
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Making all in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
  CXX      BitVector.lo
  CXX      LinkedLists.lo
  CXX      Sockets.lo
  CXX      Threads.lo
  CXX      Logger.lo
  CXX      Timeval.lo
  CXXLD    libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making all in GSM
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
  CXX      GSMCommon.lo
  CXXLD    libGSM.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making all in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in arm
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making all in x86
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
  CC       convolve.lo
  CC       convert.lo
  CC       libarch_sse_3_la-convert_sse_3.lo
  CC       libarch_sse_3_la-convolve_sse_3.lo
  CC       ../common/convolve_base.lo
  CC       libarch_sse_4_1_la-convert_sse_4_1.lo
  CC       ../common/convert_base.lo
  CCLD     libarch_sse_4_1.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch_sse_3.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
  CXX      radioInterface.lo
  CXX      radioBuffer.lo
  CXX      sigProcLib.lo
  CXX      radioVector.lo
  CXX      signalVector.lo
  CXX      radioClock.lo
  CXX      Transceiver.lo
  CXX      ChannelizerBase.lo
  CXX      Channelizer.lo
  CXX      Synthesis.lo
  CC       common/fft.lo
  CXX      Resampler.lo
  CXX      radioInterfaceResamp.lo
  CXX      radioInterfaceMulti.lo
  CXX      UHDDevice.lo
  CXX      osmo-trx.o
  CXXLD    libtransceiver.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CXXLD    osmo-trx
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in tests
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making all in CommonLibs
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
  CXX      BitVectorTest.o
  CXX      InterthreadTest.o
  CXX      SocketsTest.o
  CXX      PRBSTest.o
  CXX      VectorTest.o
  CXX      TimevalTest.o
  CXX      LogTest.o
  CXXLD    PRBSTest
  CXXLD    SocketsTest
  CXXLD    BitVectorTest
  CXXLD    TimevalTest
  CXXLD    VectorTest
  CXXLD    InterthreadTest
  CXXLD    LogTest
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making all in Transceiver52M
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
  CC       convolve_test-convolve_test.o
  CCLD     convolve_test
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ make install
Making install in CommonLibs
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making install in GSM
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making install in Transceiver52M
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in arm
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making install in x86
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
  /bin/bash /home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/libtool   --mode=install /usr/bin/install -c osmo-trx '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
libtool: install: /usr/bin/install -c osmo-trx /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in tests
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making install in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making install in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ popd
~/osmo-ci/coverity/source-Osmocom
Emitted 2324 C/C++ compilation units (100%) successfully

2324 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
+ cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom
+ rm -f Osmocom.tgz
+ tar czf Osmocom.tgz cov-int
+ set +x
curl \
 --form token="$token" \
 --form email=holger at freyther.de --form file=@Osmocom.tgz \
 --form version=Version --form description=AutoUpload \
 https://scan.coverity.com/builds?project=Osmocom
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com'
Build step 'Execute shell' marked build as failure


From nhofmeyr at sysmocom.de  Fri Feb 23 02:50:46 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 23 Feb 2018 03:50:46 +0100
Subject: docker-playground and make -C
Message-ID: <20180223025046.GA4055@my.box>

About git://git.osmocom.org/docker-playground -- I just hit an obscure case
that got me really confused:

In debian-stretch-titan/, the docker image that is built will obviously be
tagged 'debian-stretch-titan', from $PWD.

However, when I do, from the root dir:

  make -C debian-stretch-titan

then somehow the $PWD is still resolved in the root dir, and all of my images
get tagged as 'docker-playground'. wtf.

So this didn't work:

  for d in debian-stretch-titan osmo-bsc-master osmo-stp-master osmo-mgw-master ttcn3-bsc-test ; do
    make -C $d
  done

It just got me lots of untagged images, and the last one tagged as
docker-playground.

but this worked:

  for d in debian-stretch-titan osmo-bsc-master osmo-stp-master osmo-mgw-master ttcn3-bsc-test ; do
    cd $d
    make
    cd ..
  done

That's one hell of a thing to be aware of there, you can try to refresh your
images all you like if they keep being tagged with the wrong names >:(

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180223/3c8433c2/attachment.bin>

From rafael at riseup.net  Fri Feb 23 03:26:13 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Fri, 23 Feb 2018 00:26:13 -0300
Subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
In-Reply-To: <8b120a9f-9a8c-86e8-f552-e8bd10294b6b@sysmocom.de>
References: <DB6PR0902MB192613FA299C814A305D7C01FFF50@DB6PR0902MB1926.eurprd09.prod.outlook.com>
 <20bb9154-e6e2-3de9-941b-482793dd3179@sysmocom.de>
 <1518811648.11238.2@smtp.migadu.com>
 <5739ba96-9bd2-9823-b2ec-27edf217d00a@sysmocom.de>
 <50f9af58-ec57-ab63-537b-818abfc36a0b@riseup.net>
 <76be64c9-ba2b-7fc5-e329-2057ff39031e@sysmocom.de>
 <219e7718-2135-e1c0-7391-cfe84c35d769@riseup.net>
 <8b120a9f-9a8c-86e8-f552-e8bd10294b6b@sysmocom.de>
Message-ID: <7bda6a4d-67ea-4b57-6e90-d730b8845089@riseup.net>

Worked - I have voice! Thanks Pau.

But GPRS is not ok yet. I'm running osmo-bts-lc15 and osmo-pcu in the
LC15, and the core network in my development pc.

osmo-sgsn gives me:

20180223001319967 DMM <0002> gprs_sgsn.c:726
MM(724056406933460/ccb930f7) Subscriber data update
20180223001319967 DMM <0002> sgsn_auth.c:219
MM(724056406933460/ccb930f7) Updating authorization (unknown ->
authenticate)
20180223001319967 DMM <0002> sgsn_auth.c:236
MM(724056406933460/ccb930f7) Missing auth tuples, authorization not possible
20180223001319967 DMM <0002> sgsn_auth.c:248
MM(724056406933460/ccb930f7) Got authorization update: state unknown ->
rejected
20180223001319967 DMM <0002> gprs_gmm.c:1140
MM(724056406933460/ccb930f7) Not authorized, rejecting ATTACH REQUEST
with cause 'IMSI unknown in HLR' (2)
20180223001319967 DMM <0002> gprs_gmm.c:489 MM(724056406933460/ccb930f7)
<- GPRS ATTACH REJECT: IMSI unknown in HLR

But I added the IMSIs in HLR with
subscriber imsi 724056406933460 create
subscriber imsi 724056406933460 update msisdn 12345678

I run (nightly builds):
osmo-stp -c osmo-stp.cfg
osmo-bsc -c osmo-bsc-lc15.cfg
osmo-msc -c osmo-msc.cfg
osmo-hlr -l hlr.db -c osmo-hlr.cfg
osmo-mgw -c osmo-mgw-msc.cfg
osmo-mgw -c osmo-mgw-bsc.cfg
osmo-sgsn -c osmo-sgsn.cfg
sudo osmo-ggsn -c osmo-ggsn.cfg

Attached goes my configuration files.

Cheers,
Rafael Diniz

On 02/21/2018 12:36 PM, Pau Espin Pedrol wrote:
> 
> 
> On 21/02/18 14:09, Rafael Diniz wrote:
>> Hi Pau,
>> Can I use loopback addresses or should I use local network addresses?
>>
> 
> Unless I'm forgetting some detail, it shuld be fine to run everything
> with loopback addresses.
> 
>> Btw, osmo-bsc_mgcp still need to be called together with current git
>> osmo-msc and osmo-mgw, right?
> 
> As far as I know latest osmo-msc already requires osmo-mgw.
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmocom_configs.tar.gz
Type: application/gzip
Size: 2738 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180223/ac12e569/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180223/ac12e569/attachment-0001.bin>

From laforge at gnumonks.org  Fri Feb 23 08:57:52 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 23 Feb 2018 09:57:52 +0100
Subject: fairwaves HO patches
In-Reply-To: <20180222235815.GA702@my.box>
References: <gerrit.1486741011493.Iad3cf545b2f7e16276466cc37dd7a1e7858467e5@gerrit.osmocom.org>
 <20180115214505.GC14510@my.box>
 <CA+QHiD-iLf_fiYu3SwommvsmTb_B+5rnE+VUGGD6FFNvSxfd_Q@mail.gmail.com>
 <20180222235815.GA702@my.box>
Message-ID: <20180223085752.GN16326@nataraja>

Hi Neels,

On Fri, Feb 23, 2018 at 12:58:15AM +0100, Neels Hofmeyr wrote:
> > Yes, handover can be initiated in any mode of lchan and we saw handovers
> > for lchans in GSM48_CMODE_SIGN mode.
> > So I think we should be able to cover this case because I didn't find any
> > mention in the specs that this case is prohibited for HO.
> > I don't know if HO is allowed for CSD (GSM48_CMODE_DATA_*), it should be
> > checked.
> > But if it is prohibited for CSD, I think we should check and block it on
> > the stage of bsc_handover_start or earlier.
> 
> So, what is CMODE_DATA, is it for PDCH / GPRS data?

It is, ad Ivan stated, for CSD (circuit switched data).  Which was never fully
implemented in OsmoBSC at all, only very partially and only with nanoBTS.  None
f the OsmoBTS code / PHYs support it, and not our TRAU frame handling for the E1/T1 BTSs.

So basically, it is unsupported :)

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


From jenkins at lists.osmocom.org  Sat Feb 24 02:29:13 2018
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Sat, 24 Feb 2018 02:29:13 +0000 (GMT)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #23
In-Reply-To: <112303554.1039.1519352949710.JavaMail.jenkins@jenkins.osmocom.org>
References: <112303554.1039.1519352949710.JavaMail.jenkins@jenkins.osmocom.org>
Message-ID: <2118192448.1101.1519439354012.JavaMail.jenkins@jenkins.osmocom.org>

See <http://jenkins.osmocom.org/jenkins/job/osmocom-coverity/23/display/redirect>

------------------------------------------
[...truncated 1.10 MB...]
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking for LIBOSMOCORE... yes
checking for UHD... no
checking for UHD... yes
checking whether C compiler accepts -msse3... yes
checking whether C compiler accepts -msse4.1... yes
checking whether gcc has __builtin_cpu_supports built-in... yes
checking for LIBUSB... yes
checking for FFTWF... yes
checking boost/config.hpp usability... yes
checking boost/config.hpp presence... yes
checking for boost/config.hpp... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating CommonLibs/Makefile
config.status: creating GSM/Makefile
config.status: creating Transceiver52M/Makefile
config.status: creating Transceiver52M/arm/Makefile
config.status: creating Transceiver52M/x86/Makefile
config.status: creating tests/Makefile
config.status: creating tests/CommonLibs/Makefile
config.status: creating tests/Transceiver52M/Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 6
make  all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Making all in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
  CXX      BitVector.lo
  CXX      Sockets.lo
  CXX      LinkedLists.lo
  CXX      Timeval.lo
  CXX      Threads.lo
  CXX      Logger.lo
  CXXLD    libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making all in GSM
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
  CXX      GSMCommon.lo
  CXXLD    libGSM.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making all in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in arm
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making all in x86
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
  CC       convert.lo
  CC       libarch_sse_3_la-convolve_sse_3.lo
  CC       libarch_sse_3_la-convert_sse_3.lo
  CC       convolve.lo
  CC       ../common/convolve_base.lo
  CC       libarch_sse_4_1_la-convert_sse_4_1.lo
  CC       ../common/convert_base.lo
  CCLD     libarch_sse_3.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch_sse_4_1.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libarch.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
  CXX      radioInterface.lo
  CXX      radioVector.lo
  CXX      radioClock.lo
  CXX      radioBuffer.lo
  CXX      signalVector.lo
  CXX      sigProcLib.lo
  CXX      Transceiver.lo
  CXX      ChannelizerBase.lo
  CXX      Channelizer.lo
  CXX      Synthesis.lo
  CC       common/fft.lo
  CXX      Resampler.lo
  CXX      radioInterfaceResamp.lo
  CXX      radioInterfaceMulti.lo
  CXX      UHDDevice.lo
  CXX      osmo-trx.o
  CXXLD    libtransceiver.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CXXLD    osmo-trx
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in tests
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making all in CommonLibs
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
  CXX      BitVectorTest.o
  CXX      SocketsTest.o
  CXX      TimevalTest.o
  CXX      InterthreadTest.o
  CXX      VectorTest.o
  CXX      PRBSTest.o
  CXX      LogTest.o
  CXXLD    BitVectorTest
  CXXLD    SocketsTest
  CXXLD    VectorTest
  CXXLD    PRBSTest
  CXXLD    TimevalTest
  CXXLD    InterthreadTest
  CXXLD    LogTest
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making all in Transceiver52M
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
  CC       convolve_test-convolve_test.o
  CCLD     convolve_test
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ make install
Making install in CommonLibs
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making install in GSM
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making install in Transceiver52M
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in arm
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arm'
Making install in x86
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/x86'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
  /bin/bash /home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/libtool   --mode=install /usr/bin/install -c osmo-trx '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin'
libtool: install: /usr/bin/install -c osmo-trx /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2'
 /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
 /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making install in tests
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
Making install in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs'
Making install in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests'
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
+ popd
~/osmo-ci/coverity/source-Osmocom
Emitted 2324 C/C++ compilation units (100%) successfully

2324 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
+ cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom
+ rm -f Osmocom.tgz
+ tar czf Osmocom.tgz cov-int
+ set +x
curl \
 --form token="$token" \
 --form email=holger at freyther.de --form file=@Osmocom.tgz \
 --form version=Version --form description=AutoUpload \
 https://scan.coverity.com/builds?project=Osmocom
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com'
Build step 'Execute shell' marked build as failure


From rafael at riseup.net  Sun Feb 25 03:50:54 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Sun, 25 Feb 2018 00:50:54 -0300
Subject: Help with GPRS and new split stack
Message-ID: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>

Hi all,
I'm running the new split stack on a LC 15 (osmo-bts and osmo-pcu from
stock LC15, and osmo-bsc, osmo-msc, osmo-stp, osmo-hlr, ... from debian
9 armv7l nightly in a chroot).

osmo-sgsn gives me:

0180225034309988 DGPRS <000f> gprs_subscriber.c:714
SUBSCR(250026920931392) Received GSUP message
OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR
20180225034309988 DGPRS <000f> gprs_subscriber.c:470
SUBSCR(250026920931392) Send authentication info has failed with cause
2, handled as: Permission denied
20180225034309988 DGPRS <000f> gprs_subscriber.c:478
SUBSCR(250026920931392) GPRS send auth info req failed, access denied,
GMM cause = 'IMSI unknown in HLR' (2)
20180225034309988 DGPRS <000f> gprs_subscriber.c:828
SUBSCR(250026920931392) Updating subscriber authentication info
20180225034309988 DMM <0002> gprs_sgsn.c:726
MM(250026920931392/e550701e) Subscriber data update
20180225034309988 DMM <0002> sgsn_auth.c:219
MM(250026920931392/e550701e) Updating authorization (unknown ->
authenticate)
20180225034309988 DMM <0002> sgsn_auth.c:236
MM(250026920931392/e550701e) Missing auth tuples, authorization not possible
20180225034309988 DMM <0002> sgsn_auth.c:248
MM(250026920931392/e550701e) Got authorization update: state unknown ->
rejected
20180225034309988 DMM <0002> gprs_gmm.c:1140
MM(250026920931392/e550701e) Not authorized, rejecting ATTACH REQUEST
with cause 'IMSI unknown in HLR' (2)
20180225034309988 DMM <0002> gprs_gmm.c:489 MM(250026920931392/e550701e)
<- GPRS ATTACH REJECT: IMSI unknown in HLR
20180225034309988 DMM <0002> gprs_gmm.c:313 MM(250026920931392/e550701e)
Cleaning MM context due to GPRS ATTACH REJECT

osmo-hlr:

20180225034401485 DAUC <0003> db_auc.c:129 IMSI='250026920931392': No 2G
Auth Data
20180225034401485 DAUC <0003> db_auc.c:165 IMSI='250026920931392': No 3G
Auth Data
20180225034401485 DAUC <0003> hlr.c:79 250026920931392: IMSI known, but
has no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via
GSUP

But I added the IMSIs in the HLR.
Which kind of auth data should I put to a SIM card from a mainstream
carrier?

Thanks,
Rafael Diniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180225/c59bff89/attachment.bin>

From axilirator at gmail.com  Sun Feb 25 18:18:37 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 26 Feb 2018 01:18:37 +0700
Subject: Help with GPRS and new split stack
Message-ID: <CAPEnp=bMzW0=BGTxRJbOG5HbjDB7QAQSPSpUiVzvn1wPXwuM-g@mail.gmail.com>

Hi Rafael,

Please pay your attention at the following warnings:

> hlr.c:79 250026920931392: IMSI known, but has no auth data;
> Returning slightly inaccurate cause 'IMSI Unknown' via GSUP

and

> sgsn_auth.c:236 MM(250026920931392/e550701e)
> Missing auth tuples, authorization not possible
> sgsn_auth.c:248 MM(250026920931392/e550701e)
> Got authorization update: state unknown -> rejected

Are you sure you do have all required auth information in HLR?

> IMSI 250 02 6920931392

BTW: is it a random IMSI? Otherwise, this IMSI belongs to a
Russian carrier - Megafon. If I am correct, and this SIM is
a commercial SIM, you won't be able to get the auth data for them.

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

From holger at freyther.de  Sun Feb 25 22:08:13 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 25 Feb 2018 22:08:13 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
 <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
 <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>
Message-ID: <56C2A12A-7051-452F-85D8-159D83BA303F@freyther.de>



> On 7. Feb 2018, at 09:31, Holger Freyther <holger at freyther.de> wrote:
> 

Hey,


> Knowing what I know now I would have gone for Go. It is made for the kind of
> concurrency where python seems unusable. I hesitated to build my own event
> loop but will build something that looks like our C apps in python (single
> select, no async/await).


finally... still plenty of things to improve and do... The next thing is to
improve "mobile" to not add the >30s timeout for first cell selection.



python3 -mosmo_ms_driver
22:59:56.255200 ---                                -: Going to store files in  {tmp_dir='/tmp/tmp5wbisu2hosmo-ms-driver'}
22:59:56.256180 run                          lu_test: Starting testcase
22:59:56.256813 run                          lu_test: Pre-launching all virtphy's
22:59:56.257391 run                    osmo-ms/00000: Starting virtphy process  [lu_test?osmo-ms/00000]
22:59:56.258454 run                    osmo-ms/00000: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00000  [lu_test?osmo-ms/00000]
22:59:56.262654 run                    osmo-ms/00001: Starting virtphy process  [lu_test?osmo-ms/00001]
22:59:56.262793 run                    osmo-ms/00001: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00001  [lu_test?osmo-ms/00001]
22:59:56.269087 run                    osmo-ms/00002: Starting virtphy process  [lu_test?osmo-ms/00002]
22:59:56.269241 run                    osmo-ms/00002: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00002  [lu_test?osmo-ms/00002]
22:59:56.274869 run                    osmo-ms/00003: Starting virtphy process  [lu_test?osmo-ms/00003]
22:59:56.275031 run                    osmo-ms/00003: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00003  [lu_test?osmo-ms/00003]
22:59:56.280416 run                    osmo-ms/00004: Starting virtphy process  [lu_test?osmo-ms/00004]
22:59:56.280570 run                    osmo-ms/00004: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00004  [lu_test?osmo-ms/00004]
22:59:56.285699 run                    osmo-ms/00005: Starting virtphy process  [lu_test?osmo-ms/00005]
22:59:56.285809 run                    osmo-ms/00005: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00005  [lu_test?osmo-ms/00005]
22:59:56.291308 run                    osmo-ms/00006: Starting virtphy process  [lu_test?osmo-ms/00006]
22:59:56.291488 run                    osmo-ms/00006: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00006  [lu_test?osmo-ms/00006]
22:59:56.300046 run                    osmo-ms/00007: Starting virtphy process  [lu_test?osmo-ms/00007]
22:59:56.300352 run                    osmo-ms/00007: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00007  [lu_test?osmo-ms/00007]
22:59:56.306980 run                    osmo-ms/00008: Starting virtphy process  [lu_test?osmo-ms/00008]
22:59:56.307134 run                    osmo-ms/00008: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00008  [lu_test?osmo-ms/00008]
22:59:56.312373 run                    osmo-ms/00009: Starting virtphy process  [lu_test?osmo-ms/00009]
22:59:56.312526 run                    osmo-ms/00009: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00009  [lu_test?osmo-ms/00009]
22:59:56.319714 run                          lu_test: Checking if sockets are in the filesystem
22:59:56.539503 run                    osmo-ms/00000: Starting process  [lu_test?osmo-ms/00000]
22:59:56.539977 run                    osmo-ms/00000: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00000.cfg --vty-port=0  [lu_test?osmo-ms/00000]
22:59:56.607714 run                          lu_test: MS start registered  {at=282743.473796635, delay=0.06289598299190402, ms=00000}
23:00:09.926047 run                    osmo-ms/00001: Starting process  [lu_test?osmo-ms/00001]
23:00:09.926563 run                    osmo-ms/00001: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00001.cfg --vty-port=0  [lu_test?osmo-ms/00001]
23:00:09.994826 run                          lu_test: MS start registered  {at=282756.860905894, delay=0.06362233200343326, ms=00001}
23:00:15.424151 run                    osmo-ms/00002: Starting process  [lu_test?osmo-ms/00002]
23:00:15.425052 run                    osmo-ms/00002: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00002.cfg --vty-port=0  [lu_test?osmo-ms/00002]
23:00:15.488956 run                          lu_test: MS start registered  {at=282762.355019533, delay=0.05711088899988681, ms=00002}
23:00:19.724246 run                    osmo-ms/00003: Starting process  [lu_test?osmo-ms/00003]
23:00:19.724996 run                    osmo-ms/00003: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00003.cfg --vty-port=0  [lu_test?osmo-ms/00003]
23:00:19.785684 run                          lu_test: MS start registered  {at=282766.651760042, delay=0.05416889599291608, ms=00003}
23:00:23.325812 run                    osmo-ms/00004: Starting process  [lu_test?osmo-ms/00004]
23:00:23.326760 run                    osmo-ms/00004: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00004.cfg --vty-port=0  [lu_test?osmo-ms/00004]
23:00:23.393305 run                          lu_test: MS start registered  {at=282770.259381962, delay=0.06159330299124122, ms=00004}
23:00:26.427752 run                    osmo-ms/00005: Starting process  [lu_test?osmo-ms/00005]
23:00:26.428336 run                    osmo-ms/00005: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00005.cfg --vty-port=0  [lu_test?osmo-ms/00005]
23:00:26.494263 run                          lu_test: MS start registered  {at=282773.360336693, delay=0.059708705986849964, ms=00005}
23:00:29.627894 run                    osmo-ms/00006: Starting process  [lu_test?osmo-ms/00006]
23:00:29.628553 run                    osmo-ms/00006: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00006.cfg --vty-port=0  [lu_test?osmo-ms/00006]
23:00:29.683842 run                          lu_test: MS start registered  {at=282776.54991861, delay=0.04898471699561924, ms=00006}
23:00:33.226115 run                    osmo-ms/00007: Starting process  [lu_test?osmo-ms/00007]
23:00:33.226723 run                    osmo-ms/00007: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00007.cfg --vty-port=0  [lu_test?osmo-ms/00007]
23:00:33.288238 run                          lu_test: MS start registered  {at=282780.154311069, delay=0.055712109024170786, ms=00007}
23:00:34.052813 run                          lu_test: MS performed LU  {at=282780.918918862, lu_delay=37.44512222701451, ms=00000}
23:00:37.525812 run                    osmo-ms/00008: Starting process  [lu_test?osmo-ms/00008]
23:00:37.526370 run                    osmo-ms/00008: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00008.cfg --vty-port=0  [lu_test?osmo-ms/00008]
23:00:37.590594 run                          lu_test: MS start registered  {at=282784.456672404, delay=0.05611523304833099, ms=00008}
23:00:43.028214 run                    osmo-ms/00009: Starting process  [lu_test?osmo-ms/00009]
23:00:43.028898 run                    osmo-ms/00009: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00009.cfg --vty-port=0  [lu_test?osmo-ms/00009]
23:00:43.087549 run                          lu_test: MS start registered  {at=282789.95362104, delay=0.05322436196729541, ms=00009}
23:00:43.087727 run                          lu_test: All started... {duration=46.56737156602321, too_slow=0}
23:00:47.231257 run                          lu_test: MS performed LU  {at=282794.097388755, lu_delay=37.23648286098614, ms=00001}
23:00:52.878843 run                          lu_test: MS performed LU  {at=282799.744935023, lu_delay=37.38991548999911, ms=00002}
23:00:56.661687 run                          lu_test: MS performed LU  {at=282803.527769994, lu_delay=36.87600995198591, ms=00003}
23:01:00.411273 run                          lu_test: MS performed LU  {at=282807.277505226, lu_delay=37.01812326401705, ms=00004}
23:01:04.194030 run                          lu_test: MS performed LU  {at=282811.06022426, lu_delay=37.699887567025144, ms=00005}
23:01:06.060154 run                          lu_test: MS performed LU  {at=282812.926287126, lu_delay=36.37636851600837, ms=00006}
23:01:09.847484 run                          lu_test: MS performed LU  {at=282816.713489132, lu_delay=36.559178063005675, ms=00007}
23:01:15.475567 run                          lu_test: MS performed LU  {at=282822.341696909, lu_delay=37.8850245049689, ms=00008}
23:01:21.124497 run                          lu_test: MS performed LU  {at=282827.990630504, lu_delay=38.037009463994764, ms=00009}
23:01:56.525619 run                          lu_test: Tests done {all_completed=True, max=38.037009463994764, min=36.37636851600837}

From nhofmeyr at sysmocom.de  Sun Feb 25 23:17:04 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 26 Feb 2018 00:17:04 +0100
Subject: Help with GPRS and new split stack
In-Reply-To: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>
References: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>
Message-ID: <20180225231704.GA20342@my.box>

On Sun, Feb 25, 2018 at 12:50:54AM -0300, Rafael Diniz wrote:
> osmo-sgsn gives me:
> MM(250026920931392/e550701e) Updating authorization (unknown ->
> authenticate)
> 20180225034309988 DMM <0002> sgsn_auth.c:236
> MM(250026920931392/e550701e) Missing auth tuples, authorization not possible
> 20180225034309988 DMM <0002> sgsn_auth.c:248
> MM(250026920931392/e550701e) Got authorization update: state unknown ->
> rejected
> 20180225034309988 DMM <0002> gprs_gmm.c:1140
> MM(250026920931392/e550701e) Not authorized, rejecting ATTACH REQUEST
> with cause 'IMSI unknown in HLR' (2)

Hi Rafael,

as Vadim pointed out, you won't be able to do Authentication without the actual
auth tuples, which you most likely do not know for an arbitrary SIM.

In 2G however, it is possible to connect without Authentication.  I think
that's done by 'auth-policy closed' and using 'ismi-acl add <your-imsi>', in
the osmo-sgsn.cfg under 'sgsn'. Then you're not using the HLR at all.

In the MSC, we have added a configuration option 'authentication optional' so
that you can use the HLR and allow missing auth data there, but the SGSN hasn't
seen attention to that detail yet. There it's all or nothing, IIRC.

Looking forward to hear your results on it...

~N



-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180226/427ad5fd/attachment.bin>

From rafael at riseup.net  Mon Feb 26 10:55:34 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Mon, 26 Feb 2018 07:55:34 -0300
Subject: Help with GPRS and new split stack
In-Reply-To: <20180225231704.GA20342@my.box>
References: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>
 <20180225231704.GA20342@my.box>
Message-ID: <d7d9d046-1716-a497-e850-d47fde36c0ea@riseup.net>

Thanks Vadim and Neels.

Vadim, you are right, it is a Russian Megafon SIM. In the context I'm
working (GSM community networks), users use "foreign" SIM cards.

Neels, today I'll try with the configuration parameters you pointed out
and see the results.

Cheers,
Rafael Diniz

On 02/25/2018 08:17 PM, Neels Hofmeyr wrote:
> On Sun, Feb 25, 2018 at 12:50:54AM -0300, Rafael Diniz wrote:
>> osmo-sgsn gives me:
>> MM(250026920931392/e550701e) Updating authorization (unknown ->
>> authenticate)
>> 20180225034309988 DMM <0002> sgsn_auth.c:236
>> MM(250026920931392/e550701e) Missing auth tuples, authorization not possible
>> 20180225034309988 DMM <0002> sgsn_auth.c:248
>> MM(250026920931392/e550701e) Got authorization update: state unknown ->
>> rejected
>> 20180225034309988 DMM <0002> gprs_gmm.c:1140
>> MM(250026920931392/e550701e) Not authorized, rejecting ATTACH REQUEST
>> with cause 'IMSI unknown in HLR' (2)
> 
> Hi Rafael,
> 
> as Vadim pointed out, you won't be able to do Authentication without the actual
> auth tuples, which you most likely do not know for an arbitrary SIM.
> 
> In 2G however, it is possible to connect without Authentication.  I think
> that's done by 'auth-policy closed' and using 'ismi-acl add <your-imsi>', in
> the osmo-sgsn.cfg under 'sgsn'. Then you're not using the HLR at all.
> 
> In the MSC, we have added a configuration option 'authentication optional' so
> that you can use the HLR and allow missing auth data there, but the SGSN hasn't
> seen attention to that detail yet. There it's all or nothing, IIRC.
> 
> Looking forward to hear your results on it...
> 
> ~N
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180226/67543cd8/attachment.bin>

From rafael at riseup.net  Tue Feb 27 02:09:35 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Mon, 26 Feb 2018 23:09:35 -0300
Subject: Help with GPRS and new split stack
In-Reply-To: <20180225231704.GA20342@my.box>
References: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>
 <20180225231704.GA20342@my.box>
Message-ID: <b55b3c26-6fa0-190a-5ba9-026efb7b8072@riseup.net>

Hi Neels,

Now I have a fully working system! GPRS working!

Thanks!
Rafael Diniz

On 02/25/2018 08:17 PM, Neels Hofmeyr wrote:
> On Sun, Feb 25, 2018 at 12:50:54AM -0300, Rafael Diniz wrote:
>> osmo-sgsn gives me:
>> MM(250026920931392/e550701e) Updating authorization (unknown ->
>> authenticate)
>> 20180225034309988 DMM <0002> sgsn_auth.c:236
>> MM(250026920931392/e550701e) Missing auth tuples, authorization not possible
>> 20180225034309988 DMM <0002> sgsn_auth.c:248
>> MM(250026920931392/e550701e) Got authorization update: state unknown ->
>> rejected
>> 20180225034309988 DMM <0002> gprs_gmm.c:1140
>> MM(250026920931392/e550701e) Not authorized, rejecting ATTACH REQUEST
>> with cause 'IMSI unknown in HLR' (2)
> 
> Hi Rafael,
> 
> as Vadim pointed out, you won't be able to do Authentication without the actual
> auth tuples, which you most likely do not know for an arbitrary SIM.
> 
> In 2G however, it is possible to connect without Authentication.  I think
> that's done by 'auth-policy closed' and using 'ismi-acl add <your-imsi>', in
> the osmo-sgsn.cfg under 'sgsn'. Then you're not using the HLR at all.
> 
> In the MSC, we have added a configuration option 'authentication optional' so
> that you can use the HLR and allow missing auth data there, but the SGSN hasn't
> seen attention to that detail yet. There it's all or nothing, IIRC.
> 
> Looking forward to hear your results on it...
> 
> ~N
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180226/2e184bf1/attachment.bin>

From ron.menez at entropysolution.com  Tue Feb 27 11:26:25 2018
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 27 Feb 2018 11:26:25 +0000
Subject: A5/1 Encryption Enabled - Programmable SIM unable to camp
Message-ID: <187747E2-D0D5-4D18-B950-B3A296DBDC95@entropysolution.com>

Hi All,

Does anyone tried enabling the A5/1 Encryption using osmo-bsc and osmo-msc?

We are using an UPBOARD with the following elements; osmo-bsc, osmo-bts-trx and osmo-trx in it; and a NUC with osmo-hlr, osmo-msc, osmo-mgcp, and osmo-stp.

Both servers are using Ubuntu 16.04 OS.

We enabled the a5/1 encryption in both osmo-bsc and osmo-msc. Then provisioned the programmable SIM to osmo-hlr with aud2g comp128v1 auth.

OsmoHLR# subscriber imsi 515941234567890 show
    ID: 9
    IMSI: 515941234567890
    MSISDN: 09271234567
    2G auth: COMP128v1
             KI=00112233445566778899aabbccddeeff

We are not really sure what causes the LOCUP Reject.

Can anyone help us with this issue?

Attached are the configuration used during the testing and a trace taken during the testing.

Best Regard,

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.cfg
Type: application/octet-stream
Size: 5339 bytes
Desc: osmo-bsc.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-hlr.cfg
Type: application/octet-stream
Size: 324 bytes
Desc: osmo-hlr.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-msc.cfg
Type: application/octet-stream
Size: 2254 bytes
Desc: osmo-msc.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-stp.cfg
Type: application/octet-stream
Size: 444 bytes
Desc: osmo-stp.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mgcp.cfg
Type: application/octet-stream
Size: 1203 bytes
Desc: mgcp.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts.cfg
Type: application/octet-stream
Size: 2356 bytes
Desc: osmo-bts.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: com128v1.pcap
Type: application/octet-stream
Size: 5804 bytes
Desc: com128v1.pcap
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/e7696c16/attachment-0006.obj>

From rafael at riseup.net  Tue Feb 27 12:30:59 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Tue, 27 Feb 2018 09:30:59 -0300
Subject: Help with GPRS and new split stack
In-Reply-To: <b55b3c26-6fa0-190a-5ba9-026efb7b8072@riseup.net>
References: <444d16fb-e970-2a42-8901-3e63045d2d53@riseup.net>
 <20180225231704.GA20342@my.box>
 <b55b3c26-6fa0-190a-5ba9-026efb7b8072@riseup.net>
Message-ID: <4f05a2de-199b-5354-21cf-89982c5d3646@riseup.net>

btw, attached goes my config, with LC15 (running everything inside ir)
IP 192.168.0.6.

Cheers,
Rafael Diniz

On 02/26/2018 11:09 PM, Rafael Diniz wrote:
> Hi Neels,
> 
> Now I have a fully working system! GPRS working!
> 
> Thanks!
> Rafael Diniz
> 
> On 02/25/2018 08:17 PM, Neels Hofmeyr wrote:
>> On Sun, Feb 25, 2018 at 12:50:54AM -0300, Rafael Diniz wrote:
>>> osmo-sgsn gives me:
>>> MM(250026920931392/e550701e) Updating authorization (unknown ->
>>> authenticate)
>>> 20180225034309988 DMM <0002> sgsn_auth.c:236
>>> MM(250026920931392/e550701e) Missing auth tuples, authorization not possible
>>> 20180225034309988 DMM <0002> sgsn_auth.c:248
>>> MM(250026920931392/e550701e) Got authorization update: state unknown ->
>>> rejected
>>> 20180225034309988 DMM <0002> gprs_gmm.c:1140
>>> MM(250026920931392/e550701e) Not authorized, rejecting ATTACH REQUEST
>>> with cause 'IMSI unknown in HLR' (2)
>>
>> Hi Rafael,
>>
>> as Vadim pointed out, you won't be able to do Authentication without the actual
>> auth tuples, which you most likely do not know for an arbitrary SIM.
>>
>> In 2G however, it is possible to connect without Authentication.  I think
>> that's done by 'auth-policy closed' and using 'ismi-acl add <your-imsi>', in
>> the osmo-sgsn.cfg under 'sgsn'. Then you're not using the HLR at all.
>>
>> In the MSC, we have added a configuration option 'authentication optional' so
>> that you can use the HLR and allow missing auth data there, but the SGSN hasn't
>> seen attention to that detail yet. There it's all or nothing, IIRC.
>>
>> Looking forward to hear your results on it...
>>
>> ~N
>>
>>
>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: juba_osmoconfig.tar.gz
Type: application/gzip
Size: 3052 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/50f44fd6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180227/50f44fd6/attachment-0001.bin>

From ron.menez at entropysolution.com  Wed Feb 28 03:42:19 2018
From: ron.menez at entropysolution.com (Ron)
Date: Wed, 28 Feb 2018 03:42:19 +0000
Subject: UMTRX - Missing IMEI in the Identity Request
Message-ID: <25BFC277-BC6F-4775-9A66-F2A44F37193C@entropysolution.com>

Hi All,

We have encountered an issue in latching/phone camping using UMTRX and OSMOCOM elements.

During the registration process, encryption command fails since the OsmoBSC/BTS does not provide the IMEI in the Identity Request.

Note that the Mobile core only permits a5/1 encryption.

This issue is not encountered using ETTUS B210 with same version of OSMOCOM elements and same configuration files.

May we know if this is a known issue?

The UHD version used is the  UHD_003.010.002.HEAD-3-g122bfae1 and the UMTRX Driver used is1.0.3-128-93d4343. We used the URL below in installing the driver and module of UMTRX:

https://umtrx.org/applications/driver/

Best Regard,

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




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

From laforge at gnumonks.org  Wed Feb 28 14:16:51 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 28 Feb 2018 15:16:51 +0100
Subject: trxcon, fake-trx and osmo-bts-trx: Simulating TA + Power Control
Message-ID: <20180228141651.GE18607@nataraja>

This is picking up on a discussion that fixeria and I have had in
https://gerrit.osmocom.org/#/c/6846 so far.

The goal is to be able to fully test the timing advance and power control loops
in unmodified osmo-bts-trx (from the BTS_Tests.ttcn test suite).

For this, we need:
* fake_trx must be able to insert additional false "delay"
* fake_trx must be able to insert additional false "path loss"

Let's look at TOA/timing first:

1) Implementation of TA in fake_trx

* MS sets timing advance via L1CTL
* trxcon translates this into SETTA command to fake_trx
* fake_trx stores this curernt TA value (in bit periods)
* fake_trx initializes the per-burst TOA (in 1/256th symbol periods) to the
  negative of those values when converting from Tx to Rx burst format,
  before feeding to osmo-bts-trx

2) implementation of "fake delay" in fake_trx

* test case at any time requests fake_trx to apply a "fake delay" (in 1/256th symbol periods)
* fake_trx stores this signed 16bit value
* fake_trx applies this fake_delay value when converting uplink Tx bursts to Rx bursts,
  after having applied the timing advance.

So a typical exchange between MS and BTS looks like this:

* testcase instructs fake_trx to apply fake_delay of 512 (2 bit periods)
* MS sends RACH burst with no timing advance at all
* fake_trx applies TA=0 and adds fake_delay value (512), resulting in
  reported timing value of 512 in the bursts passed to osmo-bts-trx
* osmo-bts-trx detects '512' and forwards this as timing offset to the BSC
* BSC will allocate a channel, and instruct MS to use TA=2 on it
* MS sends SETTA=2 to fake_trx
* any bursts from MS in fake_trx are processed as follows:
** set toa=-256*2=-512 (TA value of 2)
** add fake_delay: toa=-512 (result of above) + 512 (fake delay) = 0
* osmo-bts-trx receives bursts with toa=0, i.e. timing advance loop is balanced

When the MS is moving further away, we can simulate this by:
* testcase sends fake_delay=1024 to fake_trx
* uplink bursts now are processed in fake_trx as:
** set toa=-256*2=-512 (TA value of 2)
** add fake_delay: toa=-512 (result of above) + 1024 (fake delay) = +512
* osmo-bts-trx receives bursts with toa=512, reports this to timing advance loop code
* TA loop code will result in SACCH downlink L1 header to contain TA=4 (not just 2
  like before)
* MS will send "SETTA 4" to fake_trx
* uplink bursts now are processed in fake_trx as:
** set toa=-256*4=-1024 (TA value of 4)
** add fake_delay: toa=-1024 (result of above) + 1024 (fake delay) = 0
* loop is balanced again

For RSSI processing it's slightly more complicated:

* fake_trx would need to know the nominal transmit power of both MS and BTS.
  This could be from config file, command line argument or some control commands.
  For this example, let's assume MS nominal power is +30dBm and BTS +23 dBm
* fake_trx will have some "SET PATH LOSS" command by which the test case can tell
  it about the path loss it shall apply (in uplink and/or downlink direction)
* fake_trx receives "SET PATH LOSS 110" for 110dB path loss
* uplink burst processing then looks like this
** fake_trx knows MS nominal power is +30 dBm
** fake_trx subtracts the attenuation value from the Tx Burst Data header (e.g. 10 dB)
** fake_trx computes +30 (nominal power) -10 (burst attenuation) - 110 (path loss) = -90 dBm
** fake_trx reports -87dBm RSSI in the uplink burst to osmo-bts-trx
* downlink burst processing then looks like this
** fake_trx knows of BTS transmit power level is 23dBm
** fake_trx reads attenuation from tx burst header (e.g. 0dB)
** fake_trx computes +23 (nominal power) -0 (burst attenuation) - 110 (path loss) = -87 dBm
** fake_trx reports Rx bursts with -87dBm RSSI to trxcon

I hope this makes sense. Comments welcome.

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


From nhofmeyr at sysmocom.de  Wed Feb 28 14:18:10 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 28 Feb 2018 15:18:10 +0100
Subject: A5/1 Encryption Enabled - Programmable SIM unable to camp
In-Reply-To: <187747E2-D0D5-4D18-B950-B3A296DBDC95@entropysolution.com>
References: <187747E2-D0D5-4D18-B950-B3A296DBDC95@entropysolution.com>
Message-ID: <20180228141810.GA1709@my.box>

On Tue, Feb 27, 2018 at 11:26:25AM +0000, Ron wrote:
> Hi All,
> 
> Does anyone tried enabling the A5/1 Encryption using osmo-bsc and osmo-msc?

Hi Ron,

I have recreated your setup locally and can reproduce the error. Needless to
say that this should work and shame on us for apparently not having an
effective regression test for this :/ https://osmocom.org/issues/3017

I've tested A5/1 recently and it works for me, however, I usually have both 2G
and 3G auth keys in the HLR database. Now that I have removed the 3G tokens
from the HLR, an A5/1-COMP128v1 setup indeed fails to authenticate.

In the meantime, you can try to workaround if you also enter 3G K+OPC in the
HLR database.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180228/9deed674/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Feb 28 15:07:47 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 28 Feb 2018 16:07:47 +0100
Subject: A5/1 Encryption Enabled - Programmable SIM unable to camp
In-Reply-To: <20180228141810.GA1709@my.box>
References: <187747E2-D0D5-4D18-B950-B3A296DBDC95@entropysolution.com>
 <20180228141810.GA1709@my.box>
Message-ID: <20180228150747.GB1709@my.box>

Actually, Ron,

there is no bug here. I was quite sure of my SIM configuration, but in fact it
was programmed to use COMP128v3, not v1, and hence I got a differing SRES upon
Auth Response.

Double check that your SIM/USIM is configured to use COMP128v1 for 2G!
For example, try to configure COMP128v3 in the HLR and see if that helps.

I've rejected issue #3017 now. It all works. (Feels good to be able to say that
for a change.)

~N


-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180228/b9c4b846/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Feb 28 15:29:20 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 28 Feb 2018 16:29:20 +0100
Subject: UMTRX - Missing IMEI in the Identity Request
In-Reply-To: <25BFC277-BC6F-4775-9A66-F2A44F37193C@entropysolution.com>
References: <25BFC277-BC6F-4775-9A66-F2A44F37193C@entropysolution.com>
Message-ID: <20180228152920.GC1709@my.box>

On Wed, Feb 28, 2018 at 03:42:19AM +0000, Ron wrote:
> Hi All,
> 
> We have encountered an issue in latching/phone camping using UMTRX and OSMOCOM elements.
> 
> During the registration process, encryption command fails since the OsmoBSC/BTS does not provide the IMEI in the Identity Request.

Please clarify, various aspects of this request fail to make sense to me:

The Identity Request is just a request and does not contain any identity.  The
IMEI (or any other identity) is, if at all, provided in the Identity Response.

To obtain an IMEI, OsmoMSC needs to actively request an IMEI identity by
sending a corresponding Identity Request to the MS.

OsmoMSC has the internal flags to trigger requesting an IMEI and we have tests
for that, but it seems that we currently don't actually expose it in VTY
config, and requesting the IMEI is off by default -- we never request the IMEI.
(If you're using the HUAWEI MSC, that's a different thing of course.)

Furthermore, requesting the IMEI or not is DTAP-land and utterly independent
from the hardware used. There is absolutely no way of influencing the presence
or content of ID Requests by using a different SDR (as long as the SDR works).

Lastly, the IMEI does not relate to encryption in any way, at least not in the
specs and not in our Osmocom core network.

You don't mean IMSI, do you?

Looking forward to your clarifications...

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180228/51808c76/attachment.bin>