From edachleger at yahoo.com  Tue Aug  1 09:44:41 2017
From: edachleger at yahoo.com (Erich Dachleger)
Date: Tue, 1 Aug 2017 09:44:41 +0000 (UTC)
Subject: nano 3g s8
References: <1131472750.4957826.1501580681351.ref@mail.yahoo.com>
Message-ID: <1131472750.4957826.1501580681351@mail.yahoo.com>

Hi,Does anybody now if the nano 3g s8 is available anywhere. They seem to be out of stock on ebay.

Regards

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

From laforge at gnumonks.org  Tue Aug  1 12:10:28 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 1 Aug 2017 14:10:28 +0200
Subject: Need nano3G (S8 - Model 237A)
In-Reply-To: <5c599abe-d25a-5e6d-e1d5-077f91787be6@gmail.com>
References: <CAMG-S93fruydrJodC0S38iz8+1xHiHT4MnhZKt2Z6K4SFJVeWw@mail.gmail.com>
 <5c599abe-d25a-5e6d-e1d5-077f91787be6@gmail.com>
Message-ID: <20170801121028.mqq4ljqdzaydv3xa@nataraja>

Dear Akib, Choukoumoun and others,

as this question has been raised several times in recent days, please
let me deviate from the usual policy of strictly separating the 
Osmocom open source projects and the commercial activities of sysmocom:

At sysmocom, we are selling a "3.5G starter kit limited edition"
consisting of a small embedded PC with the Osmocom sofwtware and
a nano3G S8.  It's all pre-installed and  pre-configured, together
with 10 SIM cards.

If you ware interested in buying the nan3G S8 itself without the starter
kit, this can also be arranged.  In any case, please contact
sales at sysmocom.de with related inquiries, and keep this list about
technical discussion about the Osmocom cellular network infrastructure
projects.

The revenue generated from selling this "sysmoNITB 3.5G starter kit
limited edition" is helping us to recover at least a part of the 
many, many man-months of R&D that sysmocom invested upfront in
developing osmo-iuh, libiu and the 3.5G support in OsmoMSC, OsmoSGSN and
OsmoHLR.  Yes, some parts were funded by a grant from NLnet and parts
by a customer, but to a very large extent, it was sysmocom's hard-earned
money that was spent in paying salaries for related R&D.

So if you want to show you respect and support for us putting paid
engineers like Neels, Philipp, Pau, Max, etc. on developing things like
3.5G support, buying related products through sysmocom is definitely the
way to go.  Helping us to recover that investment also enables us to
invest more in deevloping more/new features.  We'd love to work on a LTE
MME, for example - but we can only pay our developers in those areas
where there is some revenue/fundinng.

If you instead go and buy a nano3G from e-bay or from some other source,
you are not contributing to the funding of related developments.  This
is of course legally perfectly ok.  That's what you can do with Free
Software.  However, I would encourage you to think about the bigger
picture.  If everyone bought a nano3G off ebay, we wouldn't be able to
make the investment in developing the Iu/3G related Osmocom code in the
first place.

So a polite reminder to everyone: FOSS lives from contribution.  If you
use Osmocom software, please make sure you contribute in some way,
whether by sharing the development work and contributing by code,
patches, documentation - or by buying hardware or appliances from/via
sysmocom.  I assure you, funds are spent on R&D, and not for fancy cars
(we have zero company cars), fancy offices, or the like.

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


From robert.steve07 at gmail.com  Tue Aug  1 16:25:11 2017
From: robert.steve07 at gmail.com (robert)
Date: Tue, 1 Aug 2017 19:25:11 +0300
Subject: TS 04.14 commands
Message-ID: <EC5BC016-B9C1-4175-8DDD-39025C316B0F@gmail.com>

Hi,

What are the newly implemented TS 04.14 commands used for ?


From laforge at gnumonks.org  Tue Aug  1 16:34:01 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 1 Aug 2017 18:34:01 +0200
Subject: TS 04.14 commands
In-Reply-To: <EC5BC016-B9C1-4175-8DDD-39025C316B0F@gmail.com>
References: <EC5BC016-B9C1-4175-8DDD-39025C316B0F@gmail.com>
Message-ID: <20170801163401.4youf6mkfrwise5j@nataraja>

Hi Robert,

On Tue, Aug 01, 2017 at 07:25:11PM +0300, robert wrote:
> What are the newly implemented TS 04.14 commands used for ?

to switch a mobile phone into any of the loopback modes described in
TS 04.14.  You need a phone supporting those commands, a SIM card
that contains the "special flag" as outlined in the spec in order
to use this.

This is primarily useful if you'd like to perform some RF-level testing
of the receiver in either the phone or the BTS.

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


From robert.steve07 at gmail.com  Tue Aug  1 17:37:56 2017
From: robert.steve07 at gmail.com (robert)
Date: Tue, 1 Aug 2017 20:37:56 +0300
Subject: TS 04.14 commands
In-Reply-To: <20170801163401.4youf6mkfrwise5j@nataraja>
References: <EC5BC016-B9C1-4175-8DDD-39025C316B0F@gmail.com>
 <20170801163401.4youf6mkfrwise5j@nataraja>
Message-ID: <C8DC813E-510D-42FF-8F8F-056BC40E6920@gmail.com>

Hi

I thank you for your reply.

Best regards,

On Aug 1, 2017, at 7:34 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Robert,
> 
> On Tue, Aug 01, 2017 at 07:25:11PM +0300, robert wrote:
>> What are the newly implemented TS 04.14 commands used for ?
> 
> to switch a mobile phone into any of the loopback modes described in
> TS 04.14.  You need a phone supporting those commands, a SIM card
> that contains the "special flag" as outlined in the spec in order
> to use this.
> 
> This is primarily useful if you'd like to perform some RF-level testing
> of the receiver in either the phone or the BTS.
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From ron.menez at entropysolution.com  Tue Aug  1 17:37:37 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 1 Aug 2017 17:37:37 +0000
Subject: Ring Back Tone Missing during Call Setup
In-Reply-To: <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de>
References: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com>,
 <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de>
Message-ID: <-onfya3-8niqfx-kj0irm-6bx64a-vljebe1lr0nf84xqi2-nlnnb4o77bdp2uvfg8-829zepb4g6ow-8mvxxy5a2kddno2lr252gt8k-curos8o6niv5-p7h6zn1a8zoj-2wr0kufmakyh-kauri7q5q593.1501609055384@email.android.com>

Hi Holger,

We'll check on this and will share the results.

Thanks,
Ron

Sent from my Huawei Mobile

-------- Original Message --------
Subject: Re: Ring Back Tone Missing during Call Setup
From: Holger Freyther
To: Ron
CC: openbsc at lists.osmocom.org


> On 27. Jul 2017, at 18:30, Ron <ron.menez at entropysolution.com> wrote:
>
> Hi All,
>
> I?m not sure if this is a valid question but still I?m going to try.
>
> I just updated from my old version of OSMOCOM to the latest one.
>
> Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing.
>
> Can anyone direct me to the right path where to check it?

Check if this[1] is in your checkout and being called during the call. Check what happens if you revert it. Check the diff of the MNCC log.. send a patch.

cheers
        holger

[1] http://git.osmocom.org/osmo-sip-connector/commit/?id=9d796ff15690eb313ec6d2323902f9ea677f300e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170801/80cdcd5d/attachment.htm>

From antgorka at gmail.com  Wed Aug  2 21:30:46 2017
From: antgorka at gmail.com (Anton Gorbachev)
Date: Thu, 3 Aug 2017 00:30:46 +0300
Subject: RRLP - How?
Message-ID: <CAE8qTPO31QhXcJdTpjgruTZEc7dCRCtxgmhPfRuD=xC0iMpZpg@mail.gmail.com>

Dear developers,

I found that RRLP requests are possible within OsmoNITB.
http://security.osmocom.org/trac/wiki/RRLP

The popular Free Software implementations of the GSM network ?OpenBSC
<http://openbsc.osmocom.org/> and ?OpenBTS <http://openbts.sourceforge.net/>
 both support RRLP inquiries to mobile phones
And I found it's possible to acrivate some setting in OnmoNITB but how can
I do the actual request? I cannot find anything in the user manual, vty
manual or in the menu...

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170803/82c706f0/attachment.htm>

From axilirator at gmail.com  Thu Aug  3 11:25:38 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 3 Aug 2017 17:25:38 +0600
Subject: RRLP
Message-ID: <CAPEnp=aSSyBrFeyajnBifdnjmF9grM5P6=rsqSYrrM7JZXoiDQ@mail.gmail.com>

Hi,

> And I found it's possible to acrivate some setting in
> OnmoNITB but how can I do the actual request? I cannot
> find anything in the user manual, vty manual or in the menu...

This request is being sent automatically every time when
a dedicated channel between MS and BTS is established.

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

From nhofmeyr at sysmocom.de  Mon Aug  7 10:05:46 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 7 Aug 2017 12:05:46 +0200
Subject: ip.access nano 3G S8 Configuration
In-Reply-To: <B13FDA64-ED5A-489A-8711-43EB9E7E6D73@gnumonks.org>
References: <8e610b41-0b7d-ac57-f2a5-7503b840e2e1@meathbroadband.com>
 <20170728134836.GC27101@my.box>
 <B13FDA64-ED5A-489A-8711-43EB9E7E6D73@gnumonks.org>
Message-ID: <20170807100546.GA30207@my.box>

On Fri, Jul 28, 2017 at 09:14:01PM +0200, Harald Welte wrote:
> To be very clear here: sysmocom does *not* operate any service (nor has it authority) to flash firmware images of third party manufacturers to devices.
> All we can do is to restore a backup to a device which we sold, as part of normal repair procedures.

Sorry, my mistake, I got it confused with the SysmoCell.

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

From robert.steve07 at gmail.com  Wed Aug  9 08:37:47 2017
From: robert.steve07 at gmail.com (robert)
Date: Wed, 9 Aug 2017 11:37:47 +0300
Subject: paging priority
Message-ID: <5381471C-C84D-49E3-A85B-6380B238CA86@gmail.com>

Hi,

I have noticed that when there are many MS connecting to my BTS if I try to page (call or send SMS) a specific MS it takes a long time and sometimes just fails. Is there a way to give a higher priority for paging under high network loads ?

from vty:
Current Channel Load:
	CCCH+SDCCH4: 100% (4/4)
	TCH/F: 100% (2/2)
	SDCCH8: 100% (40/40)

best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170809/e0a32c0e/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Aug  9 13:28:43 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 9 Aug 2017 15:28:43 +0200
Subject: jenkins and osmo-ci
Message-ID: <20170809132843.GB32321@my.box>

Hey Andr?,

since https://gerrit.osmocom.org/2465 is merged, do you have a patch ready that
enables the build cache for openbsc.git/contrib/jenkins.sh?

The slowness of the openbsc-gerrit builds is a drag...
We could throw more build slaves at it, but it makes sense to give the build
cache a chance first.

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

From holger at freyther.de  Wed Aug  9 11:55:31 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 9 Aug 2017 19:55:31 +0800
Subject: paging priority
In-Reply-To: <5381471C-C84D-49E3-A85B-6380B238CA86@gmail.com>
References: <5381471C-C84D-49E3-A85B-6380B238CA86@gmail.com>
Message-ID: <B76E82F0-CF28-4B0A-BA9B-8D7F7044FF52@freyther.de>


> On 9. Aug 2017, at 16:37, robert <robert.steve07 at gmail.com> wrote:
> 
> Hi,

Hey!


> I have noticed that when there are many MS connecting to my BTS if I try to page (call or send SMS) a specific MS it takes a long time and sometimes just fails. Is there a way to give a higher priority for paging under high network loads ?

if you have a busy cell and can't contribute with code. Have you considered contributing financially to the project?

At this point there is no "priority" handling. The BSC will instruct the BTS to page IMSIs round-robin. This logic can surely be changed. If you only want to provide service to a subset of MS you could use special access classes.

holger

From robert.steve07 at gmail.com  Wed Aug  9 13:52:39 2017
From: robert.steve07 at gmail.com (robert)
Date: Wed, 9 Aug 2017 16:52:39 +0300
Subject: paging priority
In-Reply-To: <B76E82F0-CF28-4B0A-BA9B-8D7F7044FF52@freyther.de>
References: <5381471C-C84D-49E3-A85B-6380B238CA86@gmail.com>
 <B76E82F0-CF28-4B0A-BA9B-8D7F7044FF52@freyther.de>
Message-ID: <18F7E88B-907E-423E-BF62-D86463359D40@gmail.com>

Hi

On Aug 9, 2017, at 2:55 PM, Holger Freyther <holger at freyther.de> wrote:

> 
>> On 9. Aug 2017, at 16:37, robert <robert.steve07 at gmail.com> wrote:
>> 
>> Hi,
> 
> Hey!
> 
> 
>> I have noticed that when there are many MS connecting to my BTS if I try to page (call or send SMS) a specific MS it takes a long time and sometimes just fails. Is there a way to give a higher priority for paging under high network loads ?
> 
> if you have a busy cell and can't contribute with code. Have you considered contributing financially to the project?
> 
> At this point there is no "priority" handling. The BSC will instruct the BTS to page IMSIs round-robin. This logic can surely be changed. If you only want to provide service to a subset of MS you could use special access classes.


Actually its not a busy cell, I only have two MS connected to it and the rest of MS trying to connect are rejected. But the problem is that the channels are being exhausted while rejecting the other MS. I only have one MS being paged in the cell but it is not always doable because of the high load. 
If I may ask the question in another way, is it possible to prevent this load by just ignoring the location update of certain MS instead of responding to them and rejecting them ?


 




From laforge at gnumonks.org  Wed Aug  9 14:10:54 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Aug 2017 16:10:54 +0200
Subject: paging priority
In-Reply-To: <18F7E88B-907E-423E-BF62-D86463359D40@gmail.com>
References: <5381471C-C84D-49E3-A85B-6380B238CA86@gmail.com>
 <B76E82F0-CF28-4B0A-BA9B-8D7F7044FF52@freyther.de>
 <18F7E88B-907E-423E-BF62-D86463359D40@gmail.com>
Message-ID: <20170809141054.iyhmkj6isfwibcvi@nataraja>

Hi Robert,

On Wed, Aug 09, 2017 at 04:52:39PM +0300, robert wrote:

> Actually its not a busy cell, I only have two MS connected to it and
> the rest of MS trying to connect are rejected. But the problem is that
> the channels are being exhausted while rejecting the other MS. 

So you're not talking about paging load or paging priority here.

What you're experiencing is SDCCH exhaustion due to high number of
concurrent accesses.

> I only have one MS being paged in the cell but it is not always doable
> because of the high load. 

The *paging* is for sure doable, as the paging channel is empty if
you're only paging a single MS.

> If I may ask the question in another way, is it possible to prevent
> this load by just ignoring the location update of certain MS instead
> of responding to them and rejecting them ?

No.  You don't know from whom a given request is, and that it actually
is a location update, until you have established a dedicated radio
channel at L1 + L2 and are receiving L3 signaling messages.

This general problem is about fundamental aspects of the GSM radio interface,
not really related to Osmocom.  There are various different solutions,
such as using SIM cards with specific access classes, making sure your
downlink signal doesn't even reach all those other MSs, properly
configuring the reject causes to make sure they permanently go away,
gradually ramping up transmit power upone enabling the cell, gradually
ramping up access control classes of the cell, using cell barring + MS
with cell-bar-override, etc.

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


From alan at kageds.com  Wed Aug  9 15:04:02 2017
From: alan at kageds.com (Alan Evans)
Date: Wed, 9 Aug 2017 16:04:02 +0100
Subject: ip.access nano 3.5G : Any advice on how to configure channel and
 power?
Message-ID: <646c2e90-da29-22cb-484e-ed4fc751f339@kageds.com>

Hello devs,

I am using a 3.5G nano starter kit and I have a problem, hopefully 
someone can give me some advice.

When I use the kit in a location with very little 3G coverage it works 
great, I scan for 3G networks, the phone sees a network '90170' and can 
register without any problems.
However if I try the same thing in a location that has very good macro 
3G coverage from several network operators, the phone can longer see my 
nano cell.

I assume the problem is due to frequency reuse and the nanocell is using 
the same UARFCN as one of the macro cells.

Does anyone have any advice on how best to find a clear frequency band 
to use?
Also does anyone know if I have to reboot the ip.access after changing 
the UARFCN using

set rfParamsCandidateList=({9800, 401, 1})


Regards
-- 
Alan R Evans
KAGE Design Services Ltd
Tel: +44 7891 773415


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



From laforge at gnumonks.org  Wed Aug  9 17:23:34 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Aug 2017 19:23:34 +0200
Subject: ip.access nano 3.5G : Any advice on how to configure channel and
 power?
In-Reply-To: <646c2e90-da29-22cb-484e-ed4fc751f339@kageds.com>
References: <646c2e90-da29-22cb-484e-ed4fc751f339@kageds.com>
Message-ID: <20170809172334.dodhopgjsbaqo6rr@nataraja>

Hi Alan,

I think unless you've moved to the US, the 850+1900 MHz bands should not
have any macro network carriers.  However, there are of course possibly
other users in that spectrum that create a high interference level for your
signal.

If you have a spectrum analyzer around, you can check the signal levels
and check which UARFCN might me most suitable.  Make sure to cover both
the uplink and the downlink part of the UARFCN.

Aside from interference, it could also be that there is simply insufficient
output power configured.  There are a number of related DMI MIB entries,
I don't recall the details right now, but the following values appear to
be related to RF power

cpichTxPowerLowerLimit (2594) = -100
cpichTxPowerUpperLimit (2595) = 500
eAgchPowerOffset (3494) = -20
eDpcchToDpcchPowerOffset (3492) = 4
eHichErgchPowerOffset (3495) = -64
cpichTxPower_001 (2531) = -99999
hsScchPowerOffset (2875) = -10
maximumPowerCapability (1863) = 130
maximumTotalWidebandTransmitPower (2593) = 0
minimumPowerCapability (2044) = 0
powerHeadroom (2567) = 8
primaryCpichPowerPercent_002 (3606) = 100
maximumAllowedUlTxPowerDch (2216) = 24
dlPowerControlPerRab_001 (3486) = ({SRB_AND_DL_RAB_TYPE_3_4_SRB (1), -30, -20}, {SRB_AND_DL_RAB_TYPE_13_6_SRB (2), -30, -20}, {SRB_AND_DL_RAB_TYPE_CS_AMR_12_2 (3), 50, -20}, {SRB_AND_DL_RAB_TYPE_CS_UNKNOWN_DL64 (4), 0, -27}, {SRB_AND_DL_RAB_TYPE_PS_IB_DL64 (5), -30, -20}, {SRB_AND_DL_RAB_TYPE_PS_IB_DL128 (6), 0, -20}, {SRB_AND_DL_RAB_TYPE_PS_IB_DL384 (7), 40, -20}, {SRB_AND_DL_RAB_TYPE_PS_IB_DL32 (8), -40, -13})
ulPowerCtrlPerRab_001 (3487) = ({SRB_AND_UL_RAB_TYPE_3_4_SRB (1), -20, 1, 2, 1, 1, 30, 80, 0, 4, 2}, {SRB_AND_UL_RAB_TYPE_13_6_SRB (2), -20, 1, 2, 1, 1, 30, 80, 0, 4, 2}, {SRB_AND_UL_RAB_TYPE_CS_AMR_12_2 (3), -27, 1, 3, 0, 1, 40, 80, 30, 6, 1}, {SRB_AND_UL_RAB_TYPE_CS_UNKNOWN_UL64 (4), -27, 1, 6, 0, -1, 70, 90, 50, 4, 2}, {SRB_AND_UL_RAB_TYPE_PS_IB_UL64 (5), -20, 1, 6, 1, 1, 70, 90, 10, 4, 2}, {SRB_AND_UL_RAB_TYPE_PS_IB_UL128 (6), -20, 1, 6, 1, 1, 60, 80, 0, 4, 2}, {SRB_AND_UL_RAB_TYPE_PS_IB_UL384 (7), -20, 1, 6, 1, 1, 100, 120, 100, 4, 2}, {SRB_AND_UL_RAB_TYPE_PS_IB_ULHS (8), -10, 1, 10, 0, 1, 40, 150, 30, 2, 1}, {SRB_AND_UL_RAB_TYPE_PS_IB_UL32 (9), -20, 1, 6, 1, 1, 50, 50, 0, 4, 2})
powerOffsetPpm (3602) = 2
rfMeanWidebandPower (1784) = 0.000000
aichPowerOffset (1264) = -5
bchPowerOffset (1295) = -20
fachPowerOffset (1342) = 20
pchPowerOffset (1482) = 20
pichPowerOffset (1491) = -5
primarySchPowerOffset (1502) = -50
sccpchTfciBitsPowerOffset (1603) = 12
secondarySchPowerOffset (1606) = -50

However, I guess it really only makes sense to start to play with those
values when attached to a transmitter tester that can actually observe
how the channel power changes.  If anyone has played with this so far,
now would be a good time to step forward :)

Another possible source of confusion could be that the phones have some
kind of logic that they don't scan on US frequency bands in case they
see macro cells on non-US bands.  This is pure hypothesis at this point.

-- 
- 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  Thu Aug 10 11:53:06 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 10 Aug 2017 13:53:06 +0200
Subject: gerrit review comments
Message-ID: <20170810115306.GA2868@my.box>

Again it is brought to my attention that my gerrit review causes annoyance.
There is a recurring theme here, so I'd like to address all patch submitters.

I feel like it's a Good Thing to mark *everything* I notice: "I've read your
patch, and these are all the details I found, in case you'd like to address
them." I see it as a courtesy towards the patch submitter.

For some reason though I turn out to upset rather than help??  My (wrong?)
impression is that these are normal reviews as I've given them as well as
received them hundreds of times over the last decade+. In my world, adjusting
my patches N times is normal, I make mistakes all the time. But I certainly
don't want to upset: I'd really like to find out what I can change to make
everyone's hacking smoother.

In all my previous projects I got used to very high code scrutiny, and when
starting on Osmocom, Holger's review of my patches has continued on the same
high level ... often I had to revisit large amounts of my code.

Thus primed, I find it hard to ignore irregularities: most of them mean the
code becomes less stable or less maintainable/readable.

Usually I'm trying to understand what the patch does or intends, and want to
make sure future readers of the code can also understand easily. The idea is to
save time in the long run.

If you disagree with me or see inconsistencies, please let me know, whether a
patch is merged or not. Maybe I oversaw something or maybe I'm just plain
wrong.

The mood I'd like to convey is: "yes, I trust you that all these patches are an
improvement. I invested some of my time in your work with the goal to merge it
soon. And here's everything that caught my attention; do you agree?"
Ideally we can reach high code standards and at the same time collaborate
productively.

None of my gerrit comments or -1 votes are intended to convey emotion...

Feel free to mail or jabber or talk to me, also privately, on these
issues anytime! And feel free to ignore nitpicks if you don't care enough.

~N

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

From ron.menez at entropysolution.com  Fri Aug 11 06:47:09 2017
From: ron.menez at entropysolution.com (Ron)
Date: Fri, 11 Aug 2017 06:47:09 +0000
Subject: Ring Back Tone Missing during Call Setup
In-Reply-To: <-onfya3-8niqfx-kj0irm-6bx64a-vljebe1lr0nf84xqi2-nlnnb4o77bdp2uvfg8-829zepb4g6ow-8mvxxy5a2kddno2lr252gt8k-curos8o6niv5-p7h6zn1a8zoj-2wr0kufmakyh-kauri7q5q593.1501609055384@email.android.com>
References: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com>
 <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de>
 <-onfya3-8niqfx-kj0irm-6bx64a-vljebe1lr0nf84xqi2-nlnnb4o77bdp2uvfg8-829zepb4g6ow-8mvxxy5a2kddno2lr252gt8k-curos8o6niv5-p7h6zn1a8zoj-2wr0kufmakyh-kauri7q5q593.1501609055384@email.android.com>
Message-ID: <7AC7BE4B-8C51-45A3-A2E3-9F26ED0CF831@entropysolution.com>

Hi Holger,

As tested, we had confirmed that the updated version of osmo-sip-connector has an issue regarding the Ring Back Tone.

The version that we had confirmed with Ring Back Tone is the "4649746798fe3074edab720302d135c74dcf3a38?.

Updated version that has no Ring Back Tone is ?9d796ff15690eb313ec6d2323902f9ea677f300e"

Thanks for the support!

Best Regard,

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




On Aug 2, 2017, at 1:37 AM, Ron <ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>> wrote:


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>
        Feedback<http://aka.ms/SafetyTipsFeedback>
Hi Holger,

We'll check on this and will share the results.

Thanks,
Ron

Sent from my Huawei Mobile

-------- Original Message --------
Subject: Re: Ring Back Tone Missing during Call Setup
From: Holger Freyther
To: Ron
CC: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>


> On 27. Jul 2017, at 18:30, Ron <ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>> wrote:
>
> Hi All,
>
> I?m not sure if this is a valid question but still I?m going to try.
>
> I just updated from my old version of OSMOCOM to the latest one.
>
> Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing.
>
> Can anyone direct me to the right path where to check it?

Check if this[1] is in your checkout and being called during the call. Check what happens if you revert it. Check the diff of the MNCC log.. send a patch.

cheers
        holger

[1] http://git.osmocom.org/osmo-sip-connector/commit/?id=9d796ff15690eb313ec6d2323902f9ea677f300e

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

From holger at freyther.de  Fri Aug 11 07:04:11 2017
From: holger at freyther.de (Holger Freyther)
Date: Fri, 11 Aug 2017 15:04:11 +0800
Subject: Ring Back Tone Missing during Call Setup
In-Reply-To: <7AC7BE4B-8C51-45A3-A2E3-9F26ED0CF831@entropysolution.com>
References: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com>
 <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de>
 <-onfya3-8niqfx-kj0irm-6bx64a-vljebe1lr0nf84xqi2-nlnnb4o77bdp2uvfg8-829zepb4g6ow-8mvxxy5a2kddno2lr252gt8k-curos8o6niv5-p7h6zn1a8zoj-2wr0kufmakyh-kauri7q5q593.1501609055384@email.android.com>
 <7AC7BE4B-8C51-45A3-A2E3-9F26ED0CF831@entropysolution.com>
Message-ID: <C2181A9F-14EA-4DAE-9F80-8E1580E08ED4@freyther.de>


> On 11. Aug 2017, at 14:47, Ron <ron.menez at entropysolution.com> wrote:
> 
> Hi Holger,


Hey!

> 
> As tested, we had confirmed that the updated version of osmo-sip-connector has an issue regarding the Ring Back Tone.
> 
> The version that we had confirmed with Ring Back Tone is the "4649746798fe3074edab720302d135c74dcf3a38?.
> 
> Updated version that has no Ring Back Tone is ?9d796ff15690eb313ec6d2323902f9ea677f300e"
> 

okay a single commit. I don't have much spare time right now. I mentioned to diff the MNCC log as well but thinking of the specific change. Is your PBX playing an early ringback?

holger

From ron.menez at entropysolution.com  Fri Aug 11 07:44:16 2017
From: ron.menez at entropysolution.com (Ron)
Date: Fri, 11 Aug 2017 07:44:16 +0000
Subject: Ring Back Tone Missing during Call Setup
In-Reply-To: <C2181A9F-14EA-4DAE-9F80-8E1580E08ED4@freyther.de>
References: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com>
 <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de>
 <-onfya3-8niqfx-kj0irm-6bx64a-vljebe1lr0nf84xqi2-nlnnb4o77bdp2uvfg8-829zepb4g6ow-8mvxxy5a2kddno2lr252gt8k-curos8o6niv5-p7h6zn1a8zoj-2wr0kufmakyh-kauri7q5q593.1501609055384@email.android.com>
 <7AC7BE4B-8C51-45A3-A2E3-9F26ED0CF831@entropysolution.com>
 <C2181A9F-14EA-4DAE-9F80-8E1580E08ED4@freyther.de>
Message-ID: <2EB83A37-1647-4339-B629-E26F9F25263B@entropysolution.com>

Hi Holger,

No. Our PBX is not playing the early ringback.

Best Regard,

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




On Aug 11, 2017, at 3:04 PM, Holger Freyther <holger at freyther.de<mailto:holger at freyther.de>> wrote:


On 11. Aug 2017, at 14:47, Ron <ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>> wrote:

Hi Holger,


Hey!


As tested, we had confirmed that the updated version of osmo-sip-connector has an issue regarding the Ring Back Tone.

The version that we had confirmed with Ring Back Tone is the "4649746798fe3074edab720302d135c74dcf3a38?.

Updated version that has no Ring Back Tone is ?9d796ff15690eb313ec6d2323902f9ea677f300e"


okay a single commit. I don't have much spare time right now. I mentioned to diff the MNCC log as well but thinking of the specific change. Is your PBX playing an early ringback?

holger

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

From pablo at gnumonks.org  Fri Aug 11 12:54:07 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Fri, 11 Aug 2017 14:54:07 +0200
Subject: Support for SMPP Delivery Receipt / GSM03.40 Status Report in master
Message-ID: <20170811125407.GA18827@salvia>

Hi!

Support for SMPP Delivery Receipt / GSM03.40 Status Report has been
now merged into master.

If you developed your own ESME, this may require changes on your side
so things doesn't break.

Basically, you have to make sure your ESME deals with esm_class =
Delivery Receipt SMPP messages.

 MS        GSM 03.40           SMSC       SMPP 3.4               ESME
  |                             |                                |
  |       SMS-DELIVER           |                                |
  |<----------------------------|                                |
  |     GSM 04.11 RP-ACK        |                                |
  |---------------------------->|                                |
  |                             |           DELIVER-SM           |
  |                             |  esm_class = Delivery Receipt  |
  |                             |------------------------------->|
  |                             |         DELIVER-SM-RESP        |
  |                             |<-------------------------------|
  |                             |                                |

In a nutshell: Your ESME should not assume a DELIVER-SM always convey a
SMS, so such DELIVER-SM should NOT be bounced back to the corresponding
SMSC as a normal SUBMIT-SM since it does not represent a SMS.

Your ESME also needs to send a Delivery Acknowledgement to the mobile
station of origin, the one that sent the SMS, so the SMSC can deliver
the corresponding GSM03.40 SMS-STATUS-REPORT.

 MS        GSM 03.40           SMSC       SMPP 3.4               ESME
  |                             |                                |
  |                             |           SUBMIT-SM            |
  |                             |    esm_class = Delivery Ack    |
  |                             |<-------------------------------|
  |                             |         SUBMIT-SM-RESP         |
  |                             |------------------------------->|
  |                             |                                |
  |     SMS-STATUS-REPORT       |                                |
  |<----------------------------|                                |
  |     GSM 04.11 RP-ACK        |                                |
  |---------------------------->|                                |
  |                             |                                |

Please, see at recent updates on utils/smpp_mirror.c, I made a number of
small patches so I could this utility to test my patches that, I think,
should be help understand the changes that you have to do on your ESME:

http://git.osmocom.org/openbsc/log/openbsc/src/utils/smpp_mirror.c

Let me know if you have any question/concern.

Thanks!


From nhofmeyr at sysmocom.de  Sat Aug 12 02:36:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 12 Aug 2017 04:36:48 +0200
Subject: libosmocore and SSE
Message-ID: <20170812023648.GC8629@my.box>

We notice that when libosmocore debian packages built on opensuse.org end up on
the cumulus3 host, we get

/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 26402 Illegal instruction     $abs_top_builddir/tests/conv/conv_gsm0503_test

(unfortunately I have no full logs, they were rotated away)

All other hosts we hit so far apparently work fine.

a) debian packages should be usable on the largest set of CPUs, we should not
build with CPU instructions we can't guarantee to be supported. So I guess we
need a --without-sse configure option in libosmocore. Makes sense?

b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it.
Is our SSE check in libosmocore's configure.ac broken? How to verify?

c) would be nice to find out what kind of host cumulus3 is; so far we know only
that it is an x86_64. https://build.opensuse.org/monitor


Ideas? Experience?

~N

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

From laforge at gnumonks.org  Sat Aug 12 07:29:14 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 12 Aug 2017 09:29:14 +0200
Subject: libosmocore and SSE
In-Reply-To: <20170812023648.GC8629@my.box>
References: <20170812023648.GC8629@my.box>
Message-ID: <20170812072914.r72jtbmm2cy2ehqk@nataraja>

Hi Neels,

On Sat, Aug 12, 2017 at 04:36:48AM +0200, Neels Hofmeyr wrote:

> a) debian packages should be usable on the largest set of CPUs, we should not
> build with CPU instructions we can't guarantee to be supported. So I guess we
> need a --without-sse configure option in libosmocore. Makes sense?

No, sorry.  We are *compiling* code for various CPU instruction sets, and deciding
at runtime, just like ffpmeg and many other projects with (optional) optimization,
too.

> b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it.
> Is our SSE check in libosmocore's configure.ac broken? How to verify?

I'm not sure why you imply the assumption that the compiler capability to generate
instructions for a certain CPU feature set should be related to the actual
capability of the CPU to execute them.

You can always generate code that you cannot execute, this is quite normal.

> c) would be nice to find out what kind of host cumulus3 is; so far we know only
> that it is an x86_64. https://build.opensuse.org/monitor

Can we somehow "cat /proc/cpuinfo" during the build and get the output of that? We
could put this in the packaging rules or even in the makefile?  Or even compile it
into the binary with something like "-DCOMPILEHOST_CPUFLAGS=`cat /proc/cpuinfo`"

I've right now tested to build + make check libosmocore.git master
on a very old x86_64 machine, one of the first processors ever to support the
instructions set.  Worked fine:

=== AMD Opteron 250
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good nopl extd_apicid

It could of course be that the packaging rules or the environment of OBS do
something odd to the compiler optimization flags that would make an
obs-built-binary behave different from a manually built one...

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


From nhofmeyr at sysmocom.de  Sat Aug 12 23:54:11 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Aug 2017 01:54:11 +0200
Subject: optional vty items are stricter than expected
Message-ID: <20170812235411.GA21354@my.box>

Trying to get the newest 2G+3G developments thru the test suites (including the
vty ones), I face a problem with this VTY definition from libosmo-sccp:

  routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]

It turns out the square braces indicating optional parameters cannot contain
spaces.

To test, I created

  foo [a] [b]

which works as

  OsmoMSC(config-msc)# foo ?
    [a]  a
  OsmoMSC(config-msc)# foo b
  % Unknown command.
  OsmoMSC(config-msc)# foo a
  ok
  OsmoMSC(config-msc)# foo a ?
    [b]  b
  OsmoMSC(config-msc)# foo a b
  ok

So far so good, but with:

  foo [a AA] [b]

I get

  OsmoMSC(config-msc)# foo ?
    [a  a
  OsmoMSC(config-msc)# foo a
  % There is no matched command.
  OsmoMSC(config-msc)# foo a val
  % Unknown command.

The way this would work is

  foo [a] [AA] [b]

and means that I can issue either 'foo', 'foo a', 'foo a val' or 'foo a val b'.
Not that helpful really.

With above command
  routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]
it seems to me it is intended as optionally providing none, si or both si and ssn?

I guess we need separate command definitions:

  routing-key RCONTEXT DPC
  routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)
  routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) ssn SSN

Does that make sense?


Until we fix it, the vty tests will not be able to match up the vty doc
parameters and the python tests will fail.

I grepped for all square brace vty definitions we have; the only ones attempting to include multiple args in square braces are in osmo_ss7_vty.c:

./libosmo-sccp/src/osmo_ss7_vty.c-265-	"update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]",
./libosmo-sccp/src/osmo_ss7_vty.c-781-	"routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}",

They aren't usable.

(the 'update route...' is part of the _sg vty command set and thus not caught
by osmo-msc or -bsc vty tests; osmo-stp has no vty tests so far, AFAICT)


These appear to be all square brace vty definitions, most enclose only a single
element and are fine:

? grep -n '\<DEFUN\>(' -A1 $(find . -name "*.c") | grep '[[]'
./osmo-sgsn/src/gprs/sgsn_vty.c-534-	"show mm-context tlli HEX [pdp]",
./osmo-sgsn/src/gprs/sgsn_vty.c-553-	"show mm-context imsi IMSI [pdp]",
./osmo-sgsn/src/gprs/sgsn_vty.c-570-	"show mm-context all [pdp]",
./osmo-sgsn/src/gprs/gb_proxy_vty.c:461:DEFUN(show_gbproxy, show_gbproxy_cmd, "show gbproxy [stats]",
./osmo-sgsn/src/gprs/gb_proxy_vty.c-552-	"delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]",
./osmo-bsc/src/osmo-bsc/osmo_bsc_vty.c-63-      "msc [<0-1000>]", "Configure MSC details\n" "MSC connection to configure\n")
./osmo-bsc/src/libbsc/bsc_vty.c:319:DEFUN(show_bts, show_bts_cmd, "show bts [<0-255>]",
./osmo-bsc/src/libbsc/bsc_vty.c:1629:DEFUN(cfg_bts_dtxu, cfg_bts_dtxu_cmd, "dtx uplink [force]",
./osmo-bsc/src/libbsc/bsc_vty.c-3947-	"bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> (activate|deactivate) (hr|fr|efr|amr) [<0-7>]",
./osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c-229-      "show mgcp [stats]",
./libosmo-sccp/src/osmo_ss7_vty.c-110-	"point-code format <1-24> [<1-23>] [<1-22>]",
./libosmo-sccp/src/osmo_ss7_vty.c-265-	"update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]",
./libosmo-sccp/src/osmo_ss7_vty.c-781-	"routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}",
./libosmo-sccp/examples/sccp_test_vty.c-39-	"connect-req <0-16777216> [DATA]",
./libosmo-sccp/examples/sccp_test_vty.c-53-	"connect-resp <0-16777216> [DATA]",
./libosmocore/src/gb/gprs_ns_vty.c:216:DEFUN(show_nse, show_nse_cmd, "show ns (nsei|nsvc) <0-65535> [stats]",
./libosmocore/src/gb/gprs_bssgp_vty.c:153:DEFUN(show_bvc, show_bvc_cmd, "show bssgp nsei <0-65535> [stats]",
./libosmocore/src/vty/command.c-2965-      "no service terminal-length [<0-512>]",
./libosmocore/src/vty/logging_vty.c-520-	"log gsmtap [HOSTNAME]",

~N

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

From nhofmeyr at sysmocom.de  Sat Aug 12 23:59:05 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Aug 2017 01:59:05 +0200
Subject: libosmocore and SSE
In-Reply-To: <20170812072914.r72jtbmm2cy2ehqk@nataraja>
References: <20170812023648.GC8629@my.box>
 <20170812072914.r72jtbmm2cy2ehqk@nataraja>
Message-ID: <20170812235905.GB21354@my.box>

On Sat, Aug 12, 2017 at 09:29:14AM +0200, Harald Welte wrote:
> You can always generate code that you cannot execute, this is quite normal.

er, of course. yes.


> I've right now tested to build + make check libosmocore.git master
> on a very old x86_64 machine, one of the first processors ever to support the
> instructions set.  Worked fine:

Did 'make check' also work?


> Can we somehow "cat /proc/cpuinfo" during the build and get the output of that? We

@lynxis, can you ask / have you asked obs yet and/or can you sneak the cat
/proc/cpuinfo in there? thx

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

From nhofmeyr at sysmocom.de  Sun Aug 13 01:00:32 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Aug 2017 03:00:32 +0200
Subject: Build failure of network:osmocom:nightly/openbsc in
 Debian_9.0/x86_64
In-Reply-To: <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
References: <build-ec4ea3176b4eed14fd8f807a450a3213@build.opensuse.org>
 <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
Message-ID: <20170813010032.GA25426@my.box>

We've seen the same in lynxis' debian builds of the split gits, and now it
makes sense: The recent openggsn changes to debian rules somehow cause an
oddity so that our configure check for libgtp now fails, causing all GPRS
related binaries to not be built.  Haven't investigated what exactly it is, but
my expectation is that openggsn causes osmo-sgsn etc to fail:

My guess is https://git.osmocom.org/openggsn/commit/?id=23eea1d132120198745dcca32728906d5f05dc5f
"Use osmocom-style git-version-gen / .version magic"
(tagged 0.94)

We try to find it by:
PKG_CHECK_MODULES(LIBGTP, libgtp >= 0.92, , found_libgtp=no)


log:

[   60s] [110/216] installing libgtp1-0.93.20170812
[...]
[   61s] [116/216] installing libgtp-dev-0.93.20170812
[...]
[  138s] checking for LIBGTP... no

https://build.opensuse.org/public/build/network:osmocom:nightly/Debian_9.0/x86_64/openbsc/_log

~N


On Fri, Aug 11, 2017 at 08:04:10PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/openbsc/Debian_9.0/x86_64
> 
> Package network:osmocom:nightly/openbsc failed to build in Debian_9.0/x86_64
> 
> Check out the package for editing:
>   osc checkout network:osmocom:nightly openbsc
> 
> Last lines of build log:
> [  176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests'
> [  176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc/tests'
> [  176s] make[3]: Entering directory '/usr/src/packages/BUILD/openbsc'
> [  176s] make[4]: Entering directory '/usr/src/packages/BUILD/openbsc'
> [  176s] make[4]: Nothing to be done for 'install-exec-am'.
> [  176s]  /bin/mkdir -p '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
> [  176s]  /usr/bin/install -c -m 644 openbsc.pc '/usr/src/packages/BUILD/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
> [  176s] make[4]: Leaving directory '/usr/src/packages/BUILD/openbsc'
> [  176s] make[3]: Leaving directory '/usr/src/packages/BUILD/openbsc'
> [  176s] make[2]: Leaving directory '/usr/src/packages/BUILD/openbsc'
> [  176s] make[1]: Leaving directory '/usr/src/packages/BUILD/openbsc'
> [  176s]    dh_install -O--sourcedirectory=openbsc
> [  176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-sgsn" (tried in "." and "debian/tmp")
> [  176s] dh_install: osmocom-sgsn missing files: /usr/bin/osmo-sgsn
> [  176s] dh_install: Cannot find (any matches for) "/usr/bin/osmo-gtphub" (tried in "." and "debian/tmp")
> [  176s] dh_install: osmo-gtphub missing files: /usr/bin/osmo-gtphub
> [  176s] dh_install: missing files, aborting
> [  176s] debian/rules:13: recipe for target 'binary' failed
> [  176s] make: *** [binary] Error 2
> [  176s] dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
> [  176s] 
> [  176s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:03:59 UTC 2017.
> [  176s] 
> [  176s] ### VM INTERACTION START ###
> [  180s] [  168.503704] reboot: Power down
> [  180s] ### VM INTERACTION END ###
> [  180s] 
> [  180s] lamb17 failed "build openbsc_0.15.1.20170811.dsc" at Fri Aug 11 20:04:03 UTC 2017.
> [  180s] 
> 
> -- 
> Configure notifications at https://build.opensuse.org/user/notifications
> openSUSE Build Service (https://build.opensuse.org/)

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

From axilirator at gmail.com  Sun Aug 13 03:31:36 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sun, 13 Aug 2017 09:31:36 +0600
Subject: libosmocore and SSE
Message-ID: <CAPEnp=aCwFMP0Y1ucAc1D-p_JeiZhphGqbrMtAqvBQW7VYugiQ@mail.gmail.com>

Hi Neels and Harald,

Is the problem related to an issue, reported by Max?
https://osmocom.org/issues/2386

As I already commented, there is one possible reason:

Currently, the conv_acc_sse.c is being compiled with
both -msse3 -msse4.1 CFLAGS. Some compilers (or different
versions) may use the msse4.1 instruction set to optimize
the whole byte code, even in the places where they are not
actually used. So, one possible solution is to separate the
conv_acc_sse.c to conv_acc_sse_3.c and conv_acc_sse_41.c,
and then compile them with -msse3 -msse4.1 flags respectively.

If I had some basic compile / check access to the build host,
I could check whether my assumption is correct.

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

From hwelte at sysmocom.de  Sun Aug 13 08:14:15 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Sun, 13 Aug 2017 10:14:15 +0200
Subject: Build failure of network:osmocom:nightly/openbsc in
 Debian_9.0/x86_64
In-Reply-To: <20170813010032.GA25426@my.box>
References: <build-ec4ea3176b4eed14fd8f807a450a3213@build.opensuse.org>
 <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
 <20170813010032.GA25426@my.box>
Message-ID: <20170813081415.yg3upfzs44fzf5ta@nataraja>

Hi Neels,

On Sun, Aug 13, 2017 at 03:00:32AM +0200, Neels Hofmeyr wrote:
> My guess is https://git.osmocom.org/openggsn/commit/?id=23eea1d132120198745dcca32728906d5f05dc5f
> "Use osmocom-style git-version-gen / .version magic" (tagged 0.94)

sorry for the fall-out.  I will investigate.

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


From laforge at gnumonks.org  Sun Aug 13 08:29:54 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Aug 2017 10:29:54 +0200
Subject: libosmocore and SSE
In-Reply-To: <20170812235905.GB21354@my.box>
References: <20170812023648.GC8629@my.box>
 <20170812072914.r72jtbmm2cy2ehqk@nataraja>
 <20170812235905.GB21354@my.box>
Message-ID: <20170813082954.taw5ugbhir4j7w3n@nataraja>

On Sun, Aug 13, 2017 at 01:59:05AM +0200, Neels Hofmeyr wrote:
> > I've right now tested to build + make check libosmocore.git master
> > on a very old x86_64 machine, one of the first processors ever to support the
> > instructions set.  Worked fine:
> 
> Did 'make check' also work?

yes, obviosuly. Sorry for not pointing that out :)

-- 
- 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 hwelte at sysmocom.de  Sun Aug 13 08:41:45 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Sun, 13 Aug 2017 10:41:45 +0200
Subject: Build failure of network:osmocom:nightly/openbsc in
 Debian_9.0/x86_64
In-Reply-To: <20170813010032.GA25426@my.box>
References: <build-ec4ea3176b4eed14fd8f807a450a3213@build.opensuse.org>
 <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
 <20170813010032.GA25426@my.box>
Message-ID: <20170813084145.7wymfjqrjfqhuqlu@nataraja>

Hi Neels,

I've tried to reproduce this, unfortunately without success.

My steps were as follows:

* install a fresh Debian 9.0 VM image from "bento/debian-9.0"
* install all build dependencies from official debian repository, namely:
  git build-essential autoconf libtool doxygen pkg-config libpcsclite-dev libtalloc-dev bumpversion
  autoconf-archive libdbi-dev libpcap-dev libssl-dev libc-ares-dev libortp-dev libsctp-dev libxml2-dev
* for pkg in libosmocore libosmo-abis libosmo-netif libosmo-sccp libsmpp34 openggsn
** git clone
** dpkg-buildpackage
** dpkg -i resulting .deb

This gets me up to a point in having openggsn + all its dependencies installed

Then I proceed with git-clone + dpkg-buildpackage for openbsc.git, and it works just as expected.
No errors. Specifically:

checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOCTRL... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOABIS... yes
checking for LIBOSMOGB... yes
checking for LIBOSMONETIF... yes
checking for LIBCRYPTO... yes
checking for LIBOSMOSCCP... yes
checking for LIBOSMOSCCP... yes
checking for LIBSMPP34... yes
checking for LIBGTP... yes
checking for LIBCARES... yes

libgtp has:
	/usr/lib/x86_64-linux-gnu/pkgconfig/libgtp.pc
and contains
	Version: 0.94.3-37d5

So I'm a bit at a loss what OBS-specific bits might be required, if it
simply builds on a plain Debian 9.

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


From laforge at gnumonks.org  Sun Aug 13 17:15:39 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Aug 2017 19:15:39 +0200
Subject: Build failure of network:osmocom:nightly/openbsc in
 Debian_9.0/x86_64
In-Reply-To: <20170813084145.7wymfjqrjfqhuqlu@nataraja>
References: <build-ec4ea3176b4eed14fd8f807a450a3213@build.opensuse.org>
 <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
 <20170813010032.GA25426@my.box>
 <20170813084145.7wymfjqrjfqhuqlu@nataraja>
Message-ID: <20170813171539.6qlc6yodvesh7qcu@nataraja>

On Sun, Aug 13, 2017 at 10:41:45AM +0200, Harald Welte wrote:
> I've tried to reproduce this, unfortunately without success.

Update: After installing my own OBS instance + workers on local machines,
I was able to reproduce this.

The culprit is libgtp.pc of those generated packages, which contains
"Version: UNKNOWN" instead of the actual version.  And the configure
script of osmo-sgsn rightfully declines to recognize this as a supported
version.

I'm not quite sure why it happens, and particularly why it only happens
in OBS.

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


From laforge at gnumonks.org  Sun Aug 13 23:04:21 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 14 Aug 2017 01:04:21 +0200
Subject: Build failure of network:osmocom:nightly/openbsc in
 Debian_9.0/x86_64
In-Reply-To: <20170813171539.6qlc6yodvesh7qcu@nataraja>
References: <build-ec4ea3176b4eed14fd8f807a450a3213@build.opensuse.org>
 <598e0dc53c425_25b5602f842725e2@build.opensuse.org>
 <20170813010032.GA25426@my.box>
 <20170813084145.7wymfjqrjfqhuqlu@nataraja>
 <20170813171539.6qlc6yodvesh7qcu@nataraja>
Message-ID: <20170813230421.lkppfvndedefl2ey@nataraja>

On Sun, Aug 13, 2017 at 07:15:39PM +0200, Harald Welte wrote:

> I'm not quite sure why it happens, and particularly why it only happens
> in OBS.

In any case, I could fix it locally using https://gerrit.osmocom.org/#/c/3508/
which I just merged and now re-triggered the OBS nightly build (3 hours after
its usual time).
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Mon Aug 14 23:24:53 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 Aug 2017 01:24:53 +0200
Subject: libosmocore and SSE
In-Reply-To: <CAPEnp=aCwFMP0Y1ucAc1D-p_JeiZhphGqbrMtAqvBQW7VYugiQ@mail.gmail.com>
References: <CAPEnp=aCwFMP0Y1ucAc1D-p_JeiZhphGqbrMtAqvBQW7VYugiQ@mail.gmail.com>
Message-ID: <20170814232453.GA27315@my.box>

On Sun, Aug 13, 2017 at 09:31:36AM +0600, Vadim Yanitskiy wrote:
> Hi Neels and Harald,
> 
> Is the problem related to an issue, reported by Max?
> https://osmocom.org/issues/2386

Indeed looks like the same error. That issue's log shows the error with
'coding_test'; We got "Illegal instruction" upon trying to run
conv_gsm0503_test. Otherwise similar.

> If I had some basic compile / check access to the build host,
> I could check whether my assumption is correct.

It's the build host 'cumulus3' running on opensuse.org, I assume we have no /
cannot get any shell access easily.

~N

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

From holger at freyther.de  Tue Aug 15 07:08:17 2017
From: holger at freyther.de (Holger Freyther)
Date: Tue, 15 Aug 2017 15:08:17 +0800
Subject: libosmocore and SSE
In-Reply-To: <20170814232453.GA27315@my.box>
References: <CAPEnp=aCwFMP0Y1ucAc1D-p_JeiZhphGqbrMtAqvBQW7VYugiQ@mail.gmail.com>
 <20170814232453.GA27315@my.box>
Message-ID: <AA241722-3E5F-428D-A587-54673BBC3CE3@freyther.de>


> On 15. Aug 2017, at 07:24, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 


> It's the build host 'cumulus3' running on opensuse.org, I assume we have no /
> cannot get any shell access easily.


cat /proc/cpuinfo
cat config.log
objdump -d tests/.libs/foo? to see which SSE routines were generated?

from the debian rules? If you already have an account you can fork it and compile it quickly. Build delays are quite small with OBS.


holger




From samir.s.abed at gmail.com  Tue Aug 15 12:03:50 2017
From: samir.s.abed at gmail.com (samir)
Date: Tue, 15 Aug 2017 15:03:50 +0300
Subject: GSM Silent call
References: <5D1B09DD-06D3-4C6F-A3C4-7ED8FE530E4F@gmail.com>
Message-ID: <F6FE1473-5BC8-4DEB-8FF2-9CBA494A49EA@gmail.com>

Hi,

I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?



From domi at tomcsanyi.net  Tue Aug 15 15:00:17 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Tue, 15 Aug 2017 17:00:17 +0200 (CEST)
Subject: GSM Silent call
In-Reply-To: <F6FE1473-5BC8-4DEB-8FF2-9CBA494A49EA@gmail.com>
References: <5D1B09DD-06D3-4C6F-A3C4-7ED8FE530E4F@gmail.com>
 <F6FE1473-5BC8-4DEB-8FF2-9CBA494A49EA@gmail.com>
Message-ID: <5CDBCD51-2BD3-4D08-BE2F-0E4FFD89CAFB@tomcsanyi.net>

Hi,

You are mislead by the name "silent call". In reality this does not make the phone transmit voice data, just a strong, high powered radio signal that could be used to locate the device/user by using it as a tracking beacon.

It is possible to send a command to an MS connected to openBSC afaik that activates this feature.

Cheers,

Domi


2017. aug. 15. d?tummal, 14:04 id?pontban samir <samir.s.abed at gmail.com> ?rta:

> Hi,
> 
> I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?
> 

From nhofmeyr at sysmocom.de  Wed Aug 16 11:46:17 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 16 Aug 2017 13:46:17 +0200
Subject: huge patches
Message-ID: <20170816114617.GA14768@my.box>

In the current osmo-msc.git split-up effort that will render openbsc.git to be
legacy, there are a couple of very large commits on gerrit. In normal
circumstances, my comment to these would be: "split this up!"

The way they came to be was: for a long time we were developing features on
branches, with numerous separate small-sized commits. There were these problems
with that:

Many commits partly or fully reverted earlier commits. It doesn't make sense to
look at small and incomplete steps in wrong directions.

Rebasing this work onto recent developments became ludicrously cumbersome:
solved merge conflicts were re-appearing with near every single following small
commit, multiplying the effort for every little conflict resolution.

It was necessary to pull these commits together to fewer steps for conflict
resolution, but some refactorings were done in-between other back-and-forth
changes; combining patches by topics would also have been prohibitive effort.

The first step was thus to plain squash *all* into *one*. That is the current
state of the libvlr changes (already merged), mscsplit changes (being merged
now), IuCS (coming up) and AoIP+sigtran (coming up).

If it serves review, I am ready and willing to split these up into smaller
bits, but if we can avoid spending time on that by reviewing the commits as
whole, we can reduce time spent on cosmetics. The special nature of these
patches is that they do pretty much completely overhaul the internal wiring and
data structures: it makes sense to look at it as a whole and it's hard to pull
out separate changes that are orthogonal.

So though this should not be the default style of our commits, this is a
special situation. Do request a split up if you see a need. Otherwise we will
merge them in these large code bombs as a basis for further dev.

Thanks!

~N

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

From laforge at gnumonks.org  Wed Aug 16 23:14:26 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 17 Aug 2017 01:14:26 +0200
Subject: huge patches
In-Reply-To: <20170816114617.GA14768@my.box>
References: <20170816114617.GA14768@my.box>
Message-ID: <20170816231426.57nxbi6cx3jv3ggz@nataraja>

Hi Neels,

On Wed, Aug 16, 2017 at 01:46:17PM +0200, Neels Hofmeyr wrote:
> If it serves review, I am ready and willing to split these up into smaller
> bits, 

My Opinion: Please let's not drag this on for any longer and spend time
on cosmetic issues like this.  With architectural changes at code at
this scale, I think there's only so much that review can resolve anyway.
We need all forms of testing to help us iron out the kinks.

Our goal is to get the review and split-up done rather soon, so we and
other can start testing, update packaging in OE, Debian, update manuals,
wiki, etc.

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


From msuraev at sysmocom.de  Thu Aug 17 09:36:18 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 17 Aug 2017 11:36:18 +0200
Subject: OBS nightly for EoL releases
Message-ID: <aa4b57f2-a336-0d1b-c1c1-9c1e1106e39e@sysmocom.de>

Hi.

We're building nightly .deb over at
https://build.opensuse.org/project/monitor/network:osmocom:nightly for several distro
flavors including Ubuntu 16.10 which is already reached End of Life stage.

Shall we just drop such EoL distros from nightly builds?

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






From laforge at gnumonks.org  Fri Aug 18 17:33:22 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 18 Aug 2017 19:33:22 +0200
Subject: OBS nightly for EoL releases
In-Reply-To: <aa4b57f2-a336-0d1b-c1c1-9c1e1106e39e@sysmocom.de>
References: <aa4b57f2-a336-0d1b-c1c1-9c1e1106e39e@sysmocom.de>
Message-ID: <20170818173322.6hpj56jf3gj52u3p@nataraja>

On Thu, Aug 17, 2017 at 11:36:18AM +0200, Max wrote:
> We're building nightly .deb over at
> https://build.opensuse.org/project/monitor/network:osmocom:nightly for several distro
> flavors including Ubuntu 16.10 which is already reached End of Life stage.
> 
> Shall we just drop such EoL distros from nightly builds?

Which particular problem do those builds cause you?  What do we gain by
removing the build?

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


From laforge at gnumonks.org  Sun Aug 20 20:41:14 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 20 Aug 2017 22:41:14 +0200
Subject: Jenkins now executing M3UA, SUA and GGSN testuite
Message-ID: <20170820204114.geh4jrb4lzieklav@nataraja>

Hi all,

Yesterday and today I've been working to get the test suites for M3UA,
SUA and GGSN(GTP) integrated into jenkins.osmocom.org.

Some more background can be found at
http://laforge.gnumonks.org/blog/20170820-osmocom-testsuites/ with links
to the respective jenkins jobs and git repositories of test cases and
Dockerfiles + Makefiles.

It's important to note that those tests are neither a competition nor a
replacement for both the unit tests as well as osmo-gsm-tester.  I'm not
quite sure how to call them, maybe "connected tests" or the like, as
they interact with our running network elements over the various
protocols/interfaces.

The parts that I'm not entirely sure about yet is:

1) does it really make sense to build docker images for both tester and IUT
   (osmo-stp in cases of M3UA/SUA tests, openggsn in case of ggsn tests)?

   Running both in docker containers attached to the same (internal,
   non-routed/public) network allows the processes to talk to each other
   without interfering the build host networking in any way, so it
   seemed like a convenient choice.

   Whether or not it makes sense to update both the tester and IUT
   container in a single jenkins job - I'm not sure.  Any ideas?

2) trigger.  So far I went for the nightly trigger at ~ 4am GMT.  This
   is sufficient for now, but it could of course be triggered by polling
   git of both the tester and the IUT.

3) version information.  I would like to get proper version information
   into jenkins, so we don't just know "nightly test on day X" but see
   on the jenkins Web UI which particular git version of IUT (and
   tester) was tested.  Any help appreciated!

4) archiving logs.  It would be great to keep the logs of not only the
   last test execution around.  Sure, jenkins has stdout (of the tester)
   and junit-xml (of the tester).  But things like the log file
   generated by the IUT is currently only present for the last test
   execution.  Any help appreciated!

I'm currently wokring on docker images for osmo-sgsn, osmo-nitb,
osmo-bts-virt and virtphy, so we can extend above-mentioned setup
to cover also the 'sysinfo + nitb vty' as well as the lapdm and pcu
tests that I wrote in TTCN-3.

After that, I plan to direct my attention more to the development of
more test casese in those respective test suites, rather than optimizing
the Jenkins integration.

Any help both with more test cases as well as jenkins would be much
appreciated.  I think the hard part has been creating the entire
toolchain and access to the various interfaces (Gp, Gb, Um, VTY, ...)
and now it should be rather easy to write more tests.

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


From laforge at gnumonks.org  Mon Aug 21 07:34:56 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Aug 2017 09:34:56 +0200
Subject: Jenkins now executing M3UA, SUA and GGSN testuite
In-Reply-To: <20170820204114.geh4jrb4lzieklav@nataraja>
References: <20170820204114.geh4jrb4lzieklav@nataraja>
Message-ID: <20170821073456.dhedy3no5adwf7it@nataraja>

Update:

On Sun, Aug 20, 2017 at 10:41:14PM +0200, Harald Welte wrote:

> I'm currently wokring on docker images for osmo-sgsn, osmo-nitb,
> osmo-bts-virt and virtphy, so we can extend above-mentioned setup
> to cover also the 'sysinfo + nitb vty' as well as the lapdm and pcu
> tests that I wrote in TTCN-3.

The 'sysinfo' TTCN-3 test series is now in jenkins, too.  First results
at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-nitb-sysinfo/8/testReport/(root)/Test/

-- 
- 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 domi at tomcsanyi.net  Mon Aug 21 08:51:50 2017
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Mon, 21 Aug 2017 10:51:50 +0200
Subject: Jenkins now executing M3UA, SUA and GGSN testuite
In-Reply-To: <20170820204114.geh4jrb4lzieklav@nataraja>
References: <20170820204114.geh4jrb4lzieklav@nataraja>
Message-ID: <8FA3FA75-12A9-400D-8E08-DB8A3A963DD6@tomcsanyi.net>

Hi,

Regarding to this topic:

> 
> 3) version information.  I would like to get proper version information
>   into jenkins, so we don't just know "nightly test on day X" but see
>   on the jenkins Web UI which particular git version of IUT (and
>   tester) was tested.  Any help appreciated!

Could this plugin be something that we can utilise to help?
https://wiki.jenkins.io/display/JENKINS/Build+Name+Setter+Plugin

As far as I can see it is capable of handling macros that can extract any kind of information, for example also something like ${GIT_REVISION,length=8} which would give us exact git versions.

Cheers,
Domi



From holger at freyther.de  Mon Aug 21 09:56:27 2017
From: holger at freyther.de (Holger Freyther)
Date: Mon, 21 Aug 2017 17:56:27 +0800
Subject: Jenkins now executing M3UA, SUA and GGSN testuite
In-Reply-To: <20170820204114.geh4jrb4lzieklav@nataraja>
References: <20170820204114.geh4jrb4lzieklav@nataraja>
Message-ID: <026906FD-469B-43BD-90B5-7C8EEF05159F@freyther.de>


> On 21. Aug 2017, at 04:41, Harald Welte <laforge at gnumonks.org> wrote:
> 
> 4) archiving logs.  It would be great to keep the logs of not only the
>   last test execution around.  Sure, jenkins has stdout (of the tester)
>   and junit-xml (of the tester).  But things like the log file
>   generated by the IUT is currently only present for the last test
>   execution.  Any help appreciated!

Jenkins can archive any kind of file.

"Post-build Actions" and then "Archive the artifacts" and then use the
Java ant "glob" to select the files you want to keep.



And please enable the "Discard build" like done for the other jobs as
well. Place on my private off-site (and sadly still partially offline)
backup is limited.


great to see more system tests.


	holger


From nhofmeyr at sysmocom.de  Tue Aug 22 14:40:25 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 Aug 2017 16:40:25 +0200
Subject: osmo-dev.git
Message-ID: <20170822144025.GA2972@ass40.sysmocom.de>

I just added a new repository: osmo-dev.git.

For a long time I have been using hacked-up tools to help me in daily
Osmocom development. A recent addition was a generator for a top-level
makefile that allows one-line do-what-I-mean rebuild.

That's the point where I thought it made sense to share, in case anyone
else is interested in this kind of convenience.

The name is taken from osmo-ci. osmo-ci is for continuous integation on
our jenkins, osmo-dev is for development at home. I considered adding to
osmo-ci, but the aims are actually different from osmo-ci.

There are two README files, one explaining how the top-level makefile
works, one in src/ explains my little git robots that are also included.
The future will bring more *.deps and *.opts configs...

osmo-dev is on gerrit, feel free to contribute / test / fix!

If you don't agree with the naming and separate repos decision, I'd be
fine to change that...

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

From nhofmeyr at sysmocom.de  Tue Aug 22 17:49:44 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 Aug 2017 19:49:44 +0200
Subject: optional vty items are stricter than expected
In-Reply-To: <20170812235411.GA21354@my.box>
References: <20170812235411.GA21354@my.box>
Message-ID: <20170822174944.GE2972@ass40.sysmocom.de>

Got no replies on this, so I guess I'll submit a patch to try and fix it.

On Sun, Aug 13, 2017 at 01:54:11AM +0200, Neels Hofmeyr wrote:
> Trying to get the newest 2G+3G developments thru the test suites (including the
> vty ones), I face a problem with this VTY definition from libosmo-sccp:
> 
>   routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]
> 
[...]
> 
> With above command
>   routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]
> it seems to me it is intended as optionally providing none, si or both si and ssn?

Actually it seems to be all permutations of {si, no-si}x{ssn, no-ssn}

> I guess we need separate command definitions:
> 
>   routing-key RCONTEXT DPC
>   routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)
>   routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) ssn SSN
and
    routing-key RCONTEXT DPC ssn SSN

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

From eprueves at gmail.com  Wed Aug 23 08:34:21 2017
From: eprueves at gmail.com (Mille Fiore)
Date: Wed, 23 Aug 2017 16:34:21 +0800
Subject: proper way to change network time/timezone
Message-ID: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>

Hello openbsc community!

We are encountering the ff issue: When using basic phones, we have observed
that the timestamps on the SMS are in UTC, even if we changed the linux
system timezone to a different one. Also, if the basic phone will do an
auto-update of date and time from the network, it will use the time in UTC.

Do you have suggestions on how to change the network timezone configuration
for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).

If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
will complain that there is a config error. If we put that under the
network level, osmo-nitb does not complain, but it doesn't seem to work as
expected.

Let me know if addtl info is needed. Thank you in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170823/378a5ce4/attachment.htm>

From alexander.chemeris at gmail.com  Wed Aug 23 11:54:55 2017
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Wed, 23 Aug 2017 14:54:55 +0300
Subject: proper way to change network time/timezone
In-Reply-To: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
Message-ID: <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>

Hello Mille,

I made a bunch of fixes for time handling in SMS back in 2014, but
those patches have never been merged master I think. If you want to
rebase them onto the current master, they may help you (or may not -
they have fixed a lot, but I don't remember about this issue
specifically).

The patches reside in the achemeris/sms_fixes branch of openbsc:
https://cgit.osmocom.org/openbsc/log/?h=achemeris/sms_fixes

On Wed, Aug 23, 2017 at 11:34 AM, Mille Fiore <eprueves at gmail.com> wrote:
> Hello openbsc community!
>
> We are encountering the ff issue: When using basic phones, we have observed
> that the timestamps on the SMS are in UTC, even if we changed the linux
> system timezone to a different one. Also, if the basic phone will do an
> auto-update of date and time from the network, it will use the time in UTC.
>
> Do you have suggestions on how to change the network timezone configuration
> for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
> vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
>
> If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb will
> complain that there is a config error. If we put that under the network
> level, osmo-nitb does not complain, but it doesn't seem to work as expected.
>
> Let me know if addtl info is needed. Thank you in advance!
>
>
>
>



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


From eprueves at gmail.com  Wed Aug 23 14:55:00 2017
From: eprueves at gmail.com (eprueves eprueves)
Date: Wed, 23 Aug 2017 22:55:00 +0800
Subject: proper way to change network time/timezone
In-Reply-To: <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
Message-ID: <CAH0qmCYPkC2KNs7GifqU_MZs3Pe7ETueBmJ1zTuMMqDYXzbUrA@mail.gmail.com>

thanks, i will take a look into it.

On Wed, Aug 23, 2017 at 7:54 PM, Alexander Chemeris <
alexander.chemeris at gmail.com> wrote:

> Hello Mille,
>
> I made a bunch of fixes for time handling in SMS back in 2014, but
> those patches have never been merged master I think. If you want to
> rebase them onto the current master, they may help you (or may not -
> they have fixed a lot, but I don't remember about this issue
> specifically).
>
> The patches reside in the achemeris/sms_fixes branch of openbsc:
> https://cgit.osmocom.org/openbsc/log/?h=achemeris/sms_fixes
>
> On Wed, Aug 23, 2017 at 11:34 AM, Mille Fiore <eprueves at gmail.com> wrote:
> > Hello openbsc community!
> >
> > We are encountering the ff issue: When using basic phones, we have
> observed
> > that the timestamps on the SMS are in UTC, even if we changed the linux
> > system timezone to a different one. Also, if the basic phone will do an
> > auto-update of date and time from the network, it will use the time in
> UTC.
> >
> > Do you have suggestions on how to change the network timezone
> configuration
> > for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
> > vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
> >
> > If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
> will
> > complain that there is a config error. If we put that under the network
> > level, osmo-nitb does not complain, but it doesn't seem to work as
> expected.
> >
> > Let me know if addtl info is needed. Thank you in advance!
> >
> >
> >
> >
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CTO/Founder, Fairwaves, Inc.
> https://fairwaves.co
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170823/c0317d8a/attachment.htm>

From pablo at gnumonks.org  Wed Aug 23 17:03:27 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Wed, 23 Aug 2017 19:03:27 +0200
Subject: proper way to change network time/timezone
In-Reply-To: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
Message-ID: <20170823170327.GB2543@salvia>

On Wed, Aug 23, 2017 at 04:34:21PM +0800, Mille Fiore wrote:
> Hello openbsc community!
> 
> We are encountering the ff issue: When using basic phones, we have observed
> that the timestamps on the SMS are in UTC, even if we changed the linux
> system timezone to a different one. Also, if the basic phone will do an
> auto-update of date and time from the network, it will use the time in UTC.
> 
> Do you have suggestions on how to change the network timezone configuration
> for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
> vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
> 
> If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
> will complain that there is a config error. If we put that under the
> network level, osmo-nitb does not complain, but it doesn't seem to work as
> expected.

I think Keith has fixed this upstream:

http://git.osmocom.org/openbsc/commit/?id=b4962dcf115148834478744e35fe1a888eda915f



From pablo at gnumonks.org  Wed Aug 23 17:07:17 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Wed, 23 Aug 2017 19:07:17 +0200
Subject: proper way to change network time/timezone
In-Reply-To: <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
Message-ID: <20170823170717.GC2543@salvia>

On Wed, Aug 23, 2017 at 02:54:55PM +0300, Alexander Chemeris wrote:
> Hello Mille,
> 
> I made a bunch of fixes for time handling in SMS back in 2014, but
> those patches have never been merged master I think. If you want to
> rebase them onto the current master, they may help you (or may not -
> they have fixed a lot, but I don't remember about this issue
> specifically).
> 
> The patches reside in the achemeris/sms_fixes branch of openbsc:
> https://cgit.osmocom.org/openbsc/log/?h=achemeris/sms_fixes

Ugh. This branch is from the stone age, 2014.

We already have status reports upstream, and many things I see there
are already fixed upstream. This includes SMPP and nitb modes.

Sorry to say, but I see nothing on that branch... I wouldn't use it
myself.


From pablo at gnumonks.org  Wed Aug 23 17:14:01 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Wed, 23 Aug 2017 19:14:01 +0200
Subject: proper way to change network time/timezone
In-Reply-To: <20170823170327.GB2543@salvia>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <20170823170327.GB2543@salvia>
Message-ID: <20170823171401.GA2869@salvia>

On Wed, Aug 23, 2017 at 07:03:27PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Aug 23, 2017 at 04:34:21PM +0800, Mille Fiore wrote:
> > Hello openbsc community!
> > 
> > We are encountering the ff issue: When using basic phones, we have observed
> > that the timestamps on the SMS are in UTC, even if we changed the linux
> > system timezone to a different one. Also, if the basic phone will do an
> > auto-update of date and time from the network, it will use the time in UTC.
> > 
> > Do you have suggestions on how to change the network timezone configuration
> > for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
> > vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
> > 
> > If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
> > will complain that there is a config error. If we put that under the
> > network level, osmo-nitb does not complain, but it doesn't seem to work as
> > expected.
> 
> I think Keith has fixed this upstream:
> 
> http://git.osmocom.org/openbsc/commit/?id=b4962dcf115148834478744e35fe1a888eda915f

Sorry, actually it's this one for libosmocore:

http://git.osmocom.org/libosmocore/commit/?id=733810c656fa9ec50a4223b0c15070ba1fd758cf


From nhofmeyr at sysmocom.de  Wed Aug 23 17:40:51 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Aug 2017 19:40:51 +0200
Subject: proper way to change network time/timezone
In-Reply-To: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
Message-ID: <20170823174051.GA4151@my.box>

On Wed, Aug 23, 2017 at 04:34:21PM +0800, Mille Fiore wrote:
> Hello openbsc community!
> 
> We are encountering the ff issue: When using basic phones, we have observed
> that the timestamps on the SMS are in UTC, even if we changed the linux
> system timezone to a different one.

This sounds like it may be fixed by the recently merged patch, which changes
the SMS' time stamp from UTC to the server's local time:
https://gerrit.osmocom.org/3551
(This came to my attention because yesterday I noticed msc_vlr unit tests
exhibiting differing H-M-S values for a timestamp of zero and needing
adjustment.)

It should already be effective in the nightly builds.
https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds

> Also, if the basic phone will do an
> auto-update of date and time from the network, it will use the time in UTC.

(not sure about this one, might be worth opening an issue for on osmocom.org)

> Do you have suggestions on how to change the network timezone configuration
> for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
> vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
> 
> If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
> will complain that there is a config error. If we put that under the
> network level, osmo-nitb does not complain, but it doesn't seem to work as
> expected.

To prepare for the (almost complete) move to separate osmo-msc and osmo-bsc
processes, I have moved the timezone settings up from BTS level to the 'net'
level:
https://git.osmocom.org/openbsc/commit/?id=7398395cc01977aa9b41c2d433b487154b60ce2a
However, I'm not that familiar with what effect it has. All I can say is that
the timezone configured on network level is used in all places where previously
the bts timezone setting was employed.

~N

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

From keith at rhizomatica.org  Wed Aug 23 17:37:50 2017
From: keith at rhizomatica.org (Keith)
Date: Wed, 23 Aug 2017 19:37:50 +0200
Subject: proper way to change network time/timezone
In-Reply-To: <20170823171401.GA2869@salvia>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <20170823170327.GB2543@salvia> <20170823171401.GA2869@salvia>
Message-ID: <76e0f9b9-a8f8-d580-4ac7-b0438b912c07@rhizomatica.org>



On 23/08/2017 19:14, Pablo Neira Ayuso wrote:
> Sorry, actually it's this one for libosmocore:
>
> http://git.osmocom.org/libosmocore/commit/?id=733810c656fa9ec50a4223b0c15070ba1fd758cf

Yes, athough that is only for the SMS timestamps. It's possible a
similar fix might apply for the general setting of the time, although I
haven't seen this problem, In fact, I've seen quite the opposite - the
phones setting their clock to the machine running osmo-notb timezone.

One thing I do notice from Alex's branch is setting TP-SCTS on the
delivery report to the datetime of the original submit.
I wasn't able to find the correct spec. here, I used the delivery time.
I also don't have a phone that cares.


From alexander.chemeris at gmail.com  Wed Aug 23 20:41:58 2017
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Wed, 23 Aug 2017 23:41:58 +0300
Subject: proper way to change network time/timezone
In-Reply-To: <20170823170717.GC2543@salvia>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
 <20170823170717.GC2543@salvia>
Message-ID: <CABmJbFWmRead=4URAdEELM91+xawwxJaHURggYLbOgvyWyyD9w@mail.gmail.com>

Hi Pablo,

On Wed, Aug 23, 2017 at 8:07 PM, Pablo Neira Ayuso <pablo at gnumonks.org> wrote:
>
> On Wed, Aug 23, 2017 at 02:54:55PM +0300, Alexander Chemeris wrote:
> > Hello Mille,
> >
> > I made a bunch of fixes for time handling in SMS back in 2014, but
> > those patches have never been merged master I think. If you want to
> > rebase them onto the current master, they may help you (or may not -
> > they have fixed a lot, but I don't remember about this issue
> > specifically).
> >
> > The patches reside in the achemeris/sms_fixes branch of openbsc:
> > https://cgit.osmocom.org/openbsc/log/?h=achemeris/sms_fixes
>
> Ugh. This branch is from the stone age, 2014.

Yes, it was a long time ago, so even I forgot what was there. It's not
related to the topic in question, but this patch is not yet merged and
I don't see this properly supported in master branch still?
https://cgit.osmocom.org/openbsc/commit/?h=achemeris/sms-validity-fix&id=c70e1282d692e376542b3f789e5340d02af78f17

But after looking a bit more into this, the patches which I *actually*
meant are in the related libosmocore:
https://cgit.osmocom.org/libosmocore/log/?h=achemeris/sms-fixes
https://cgit.osmocom.org/libosmocore/log/?h=daniel/scts-fixes

Again, I don't see this merged upstream or somehow else implemented
there unless I'm missing something?

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


From msuraev at sysmocom.de  Thu Aug 24 17:02:24 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 24 Aug 2017 19:02:24 +0200
Subject: BSC+BTS SI + LAPD validation, TTCN-3 Testsuite
In-Reply-To: <20170719184354.n7dvcyp3kif7mctz@nataraja>
References: <20170719184354.n7dvcyp3kif7mctz@nataraja>
Message-ID: <2680b34c-b1cb-f49e-b81f-f11dba62fdbc@sysmocom.de>

Great to see it's progressing!

Would it make sense to add osmo-ttcn3-hacks to gerrit to facilitate contributions?
Maybe even dropping "-hacks" part :)

I've added some dependency information to
https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Notes
Does it require particular version of eclipse-titan?

I've hit following while trying it:
...
RLCMAC_CSN1_Types.ttcn:228.19-23: error: at or before token `'B': syntax error,
unexpected Bstring, expecting Number or '-'
RLCMAC_CSN1_Types.ttcn:229.19-23: error: at or before token `'B': syntax error,
unexpected Bstring, expecting Number or '-'
...

That's when running 'make' in sysinfo subdir after gen_links.sh and regen_makefile.sh
Or maybe I'm just doing it wrong?

I've tried to run "./start-testsuite.sh sysinfo/Test.ttcn sysinfo/Test.cfg" but got
...
ttcn3_start: warning: TTCN3_DIR environment variable is not set
...
MC2> spawn ./sysinfo/Test.ttcn pbell 33117
couldn't execute "./sysinfo/Test.ttcn": permission denied
    while executing
"spawn $ETS $hostname $port"
    (file "/usr/bin/ttcn3_start" line 232)

Is it supposed to be run as root?
What shall I set TTCN3_DIR to?

-- 

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






From nhofmeyr at sysmocom.de  Thu Aug 24 17:40:27 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 24 Aug 2017 19:40:27 +0200
Subject: osmo-msc patch series from openbsc.git
Message-ID: <20170824174027.GA1997@ass40.sysmocom.de>

I rebased the recent openbsc.git patches to osmo-msc.git and am submitting
all of them on gerrit, to make sure each passes the tests. Since they are
already accepted on openbsc.git, I'll also directly +2 and merge them.

We will be re-using the same Change-Ids from openbsc.git, and I checked:
if multiple commits match the same change-id, a search on gerrit will
simply list all matches, so we're not losing any information.

https://gerrit.osmocom.org/#/q/Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f

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

From laforge at gnumonks.org  Thu Aug 24 20:50:09 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Aug 2017 22:50:09 +0200
Subject: BSC+BTS SI + LAPD validation, TTCN-3 Testsuite
In-Reply-To: <2680b34c-b1cb-f49e-b81f-f11dba62fdbc@sysmocom.de>
References: <20170719184354.n7dvcyp3kif7mctz@nataraja>
 <2680b34c-b1cb-f49e-b81f-f11dba62fdbc@sysmocom.de>
Message-ID: <20170824205009.bfcot53niv34dzab@nataraja>

Hi Max,

On Thu, Aug 24, 2017 at 07:02:24PM +0200, Max wrote:
> Great to see it's progressing!

thanks.

> Would it make sense to add osmo-ttcn3-hacks to gerrit to facilitate contributions?

sure, but I think the bigger topic at the moment is that people have to get a
working TTCN-3 setup on their system (I'm using debian 9 which has the compiler
included) and understand how to write TTCN-3 code.  gerrit is probably a rather
small step in comparison.

> Maybe even dropping "-hacks" part :)

I don't mind it that much.  we still have bsc_hack.c in openbsc.git, after all. But yes,
we could rename it to osmo-ttcn3-tests.

> I've added some dependency information to
> https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Notes
> Does it require particular version of eclipse-titan?

I'm using 6.2.0 as shipped with debian 9 (which you can see from the docker-playground.git)

> I've hit following while trying it:
> ...
> RLCMAC_CSN1_Types.ttcn:228.19-23: error: at or before token `'B': syntax error,
> unexpected Bstring, expecting Number or '-'
> RLCMAC_CSN1_Types.ttcn:229.19-23: error: at or before token `'B': syntax error,
> unexpected Bstring, expecting Number or '-'
> ...

Not sure about that.  I'm not a TITAN expert.  In case of doubt, contact
the official forum, their support is excellent.

> That's when running 'make' in sysinfo subdir after gen_links.sh and regen_makefile.sh
> Or maybe I'm just doing it wrong?
> 
> I've tried to run "./start-testsuite.sh sysinfo/Test.ttcn sysinfo/Test.cfg" but got

Replace 'Test.ttcn' with 'Test'.  You need to specify the compiled executable, not the source code.

> ttcn3_start: warning: TTCN3_DIR environment variable is not set

no problem with this

> MC2> spawn ./sysinfo/Test.ttcn pbell 33117
> couldn't execute "./sysinfo/Test.ttcn": permission denied
>     while executing

that's clear, the source code is not an executable and thus doesn't execute

> Is it supposed to be run as root?

no.

> What shall I set TTCN3_DIR to?

no need to set it, I think this is mostly in case you're not using a Debian/Distro
package but install all of TTCN3 in a /opt/... directory or the like, as opposed
to /usr/lib + /usr/share, etc.

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


From laforge at gnumonks.org  Thu Aug 24 20:51:14 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Aug 2017 22:51:14 +0200
Subject: osmo-msc patch series from openbsc.git
In-Reply-To: <20170824174027.GA1997@ass40.sysmocom.de>
References: <20170824174027.GA1997@ass40.sysmocom.de>
Message-ID: <20170824205114.acyetlactkzymmey@nataraja>

On Thu, Aug 24, 2017 at 07:40:27PM +0200, Neels Hofmeyr wrote:
> I rebased the recent openbsc.git patches to osmo-msc.git and am submitting
> all of them on gerrit, to make sure each passes the tests. Since they are
> already accepted on openbsc.git, I'll also directly +2 and merge them.

Thanks, that's great.

How to proceed with the split?  Should we review patches that are failing (-V),
or should we wait until they actually build?

-- 
- 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 eprueves at gmail.com  Fri Aug 25 07:31:53 2017
From: eprueves at gmail.com (eprueves eprueves)
Date: Fri, 25 Aug 2017 15:31:53 +0800
Subject: proper way to change network time/timezone
In-Reply-To: <CABmJbFWmRead=4URAdEELM91+xawwxJaHURggYLbOgvyWyyD9w@mail.gmail.com>
References: <CAH0qmCZ+vK7RjJ0QtduK6FaJiTuU1z_rm06J4so2o3+KKM3VWg@mail.gmail.com>
 <CABmJbFWJUcLPU7v7pB61F_FH49cZ+NPSfgRk4W-u5ri_V-dj2w@mail.gmail.com>
 <20170823170717.GC2543@salvia>
 <CABmJbFWmRead=4URAdEELM91+xawwxJaHURggYLbOgvyWyyD9w@mail.gmail.com>
Message-ID: <CAH0qmCZJrUO0MXzLBdds=WST8==Rawn7CEJaNUg85nU9pkG0Rg@mail.gmail.com>

Thank you all for the help!

I was able to solve the timestamp issue by upgrading to the latest nightly
build. My previous installation does not yet have the recent patch that
Neels mentioned.

On Thu, Aug 24, 2017 at 4:41 AM, Alexander Chemeris <
alexander.chemeris at gmail.com> wrote:

> Hi Pablo,
>
> On Wed, Aug 23, 2017 at 8:07 PM, Pablo Neira Ayuso <pablo at gnumonks.org>
> wrote:
> >
> > On Wed, Aug 23, 2017 at 02:54:55PM +0300, Alexander Chemeris wrote:
> > > Hello Mille,
> > >
> > > I made a bunch of fixes for time handling in SMS back in 2014, but
> > > those patches have never been merged master I think. If you want to
> > > rebase them onto the current master, they may help you (or may not -
> > > they have fixed a lot, but I don't remember about this issue
> > > specifically).
> > >
> > > The patches reside in the achemeris/sms_fixes branch of openbsc:
> > > https://cgit.osmocom.org/openbsc/log/?h=achemeris/sms_fixes
> >
> > Ugh. This branch is from the stone age, 2014.
>
> Yes, it was a long time ago, so even I forgot what was there. It's not
> related to the topic in question, but this patch is not yet merged and
> I don't see this properly supported in master branch still?
> https://cgit.osmocom.org/openbsc/commit/?h=achemeris/sms-validity-fix&id=
> c70e1282d692e376542b3f789e5340d02af78f17
>
> But after looking a bit more into this, the patches which I *actually*
> meant are in the related libosmocore:
> https://cgit.osmocom.org/libosmocore/log/?h=achemeris/sms-fixes
> https://cgit.osmocom.org/libosmocore/log/?h=daniel/scts-fixes
>
> Again, I don't see this merged upstream or somehow else implemented
> there unless I'm missing something?
>
> --
> Regards,
> Alexander Chemeris.
> CTO/Founder, Fairwaves, Inc.
> https://fairwaves.co
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170825/9acfe862/attachment.htm>

From laforge at gnumonks.org  Fri Aug 25 09:44:24 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 Aug 2017 11:44:24 +0200
Subject: Jenkins build slave setup / messy
Message-ID: <20170825094424.vdmqe6cfqnqkhcs5@nataraja>

Dear all,

I had to spend a large portion of my spare time last night in order to
add a new jenkins build slave in a way that it works.  What should have
been very simple by following the wiki at
https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup
turned out into a long process of failures that still continue, see
http://jenkins.osmocom.org/jenkins/job/osmo-bts-gerrit/1325/

I'm really not happy about the lack of discipline in keeping the documentation
in sync - or even bothering to state in the wiki "FIXME, some stuff
needs to be done which is not documented". Having very incomplete
documentation that suggests something is a very easy and
straight-forward task is possibly worse than having no documentation,
at which point the reader/user is clear about this being a
time-consuming procedure that involved manual recreation of a manual
setup.

We do now have "build-2.osmocom.org", which is a Ryzen 1700X eight-core
CPU with 64GB RAM.  It natively runs Debian 9 (stretch) and has a
Debian8 build slave inside a lxc container.

I've updated the wiki page, but I don't think "copy over the ~/docker directory
whose contents is not under revision control and then run ./update.sh" is
all that good an idea either.

Adding more build slaves to a jenkins setup should be the most natural and
normal thing to do.  After all, the entire system is designed to scale out
by adding more build slaves.

I think the right process here would be to have a script that generates
the build slave[s].  My preference would be to have a lxc template for
it, so any new build host simply needs to lxc-create from that template.

Is anyone willing to contribute in that area?

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


From laforge at gnumonks.org  Fri Aug 25 11:15:15 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 Aug 2017 13:15:15 +0200
Subject: jenkins build slaves: Rationale for some builds in docker vs. some
 not?
Message-ID: <20170825111515.l3lyp76cqv3cfqlh@nataraja>

Hi!

We have some builds that happen inside a docker, and some that happen natively
on the (Debian 8) build slave.  Can somebody involved with this illustrate
why that is the case, and what's the rationale here?

Just looking at the setup, I'm unable to figure out whether there's any
particular reason for this, or whether it's simply "we started without and
then did some builds in docker but nobody migrated the other builds over"

>From my point of view, I would have assumed that building in different containers
would make sense to e.g. build on different distributions / versions, or
building against older libosmo* vs. building against libosmo* from nightly
package feeds vs. re-building all dependencies from master.

But it appears that only a single container is built, and that container is
used for some jobs (like osmo-msc-gerrit) but not for other jobs.

If I missed some wiki page or mailing list posts with related information,
a pointer would be helpful.  Thanks in advance.

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


From holger at freyther.de  Fri Aug 25 12:37:12 2017
From: holger at freyther.de (Holger Freyther)
Date: Fri, 25 Aug 2017 20:37:12 +0800
Subject: jenkins build slaves: Rationale for some builds in docker vs.
 some not?
In-Reply-To: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
References: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
Message-ID: <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>


> On 25. Aug 2017, at 19:15, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi!

Hi!

> 
> We have some builds that happen inside a docker, and some that happen natively
> on the (Debian 8) build slave.  Can somebody involved with this illustrate
> why that is the case, and what's the rationale here?

historically I wanted to speed up the -gerrit builds so this is where I
started experimenting with containers and ended with docker.

For the main * build it was a question does build time matter more than
multi-platform builds. I thought that FreeBSD with clang provides more
value than a quick non-gerrit build.


> From my point of view, I would have assumed that building in different containers
> would make sense to e.g. build on different distributions / versions, or
> building against older libosmo* vs. building against libosmo* from nightly
> package feeds vs. re-building all dependencies from master.


> But it appears that only a single container is built, and that container is
> used for some jobs (like osmo-msc-gerrit) but not for other jobs.


Right a single container is used as the goal was to be able to run VTY
tests in parallel without messing with the configs (pick ports at
random or such). I think multi-distribution support should be carefully
considered as this will have an explosion in builds. It might only make
sense if we compile with -Werror as well?

I can't comment if osmo-msc-gerrit is using a different container than
other builds.


holger

From laforge at gnumonks.org  Thu Aug 31 06:46:43 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 31 Aug 2017 08:46:43 +0200
Subject: redmine e-mails broken from 08/26 through 08/31
Message-ID: <20170831064643.lyhdk5nhlahrsrsr@nataraja>

Dear Osmocom community,

from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org
redmine could not send any e-mails.  This was due to a configuration
file syntax error introduced by me, my apologies.

If you rely on redmine e-mail notifications to the issues you have
subscribed to, please double-check as related notifications during that
interval were unfortunately lost.

Best regards,
	Harald

p.s.: The reason for the config change was to enable e-mail
notifications from jenkins.osmocom.org (which it now has, if you want to
configure e.g. post-build notification actions).
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From axilirator at gmail.com  Wed Aug 30 08:50:34 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 30 Aug 2017 15:50:34 +0700
Subject: [PATCH] test/common.sh: fix typo in gapk binary location
Message-ID: <20170830085034.482-1-axilirator@gmail.com>

---
 test/common.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/common.sh b/test/common.sh
index 39cdd7d..591be3a 100644
--- a/test/common.sh
+++ b/test/common.sh
@@ -4,7 +4,7 @@ REFDIR=./ref-files
 if [ -f ../src/gapk ]; then
 	GAPK=../src/gapk
 elif [ -f `which gapk` ]; then
-	GAPK=`whiich gapk`
+	GAPK=`which gapk`
 else
 	exit 1
 fi
-- 
2.14.1



From laforge at gnumonks.org  Wed Aug 30 20:48:59 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Aug 2017 22:48:59 +0200
Subject: Wanted: OpenBSC / Osmocom users in Pakistan?
Message-ID: <20170830204859.nfmglyonl7n5jgbk@nataraja>

Hi All!

I'm wondering if there are any users of the Osmocom cellular stack in Pakistan
around.  If so, please kindly follow-up by private mail, as there might be
some projects in which your help would be appreciated.  Thanks in advance.

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 phippsr at cs.washington.edu  Wed Aug 30 19:59:13 2017
From: phippsr at cs.washington.edu (Rowan Phipps)
Date: Wed, 30 Aug 2017 19:59:13 +0000
Subject: OpenBSC USSD external application
Message-ID: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>

Hi,
I?ve been looking into getting ussd working with an external application. I
found a branch from last year (fairwaves/sup-ussd) that looks like it has
implemented most of ussd sessions and possibly communicates with an
external application. Does anyone know if it was finished or what still
needs to be done?

I also found a python script called ussd_example.py which looks like it is
supposed to act as a gateway and receive used connections from openbsc. Is
this correct and did it work or am I misunderstanding its purpose?

Thanks!
- Rowan Phipps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170830/9feeaef9/attachment.htm>

From msuraev at sysmocom.de  Mon Aug 28 12:17:11 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 28 Aug 2017 14:17:11 +0200
Subject: Osmocom release process update
Message-ID: <dac93900-7665-fcb2-f359-f8fc3b024924@sysmocom.de>

Hi.

Just a heads-up on recent changes related to Osmocom releases.

In short: read about it at
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release

Somewhat longer explanation:

In attempt to simplify and structure release process (see
https://projects.osmocom.org/issues/1861 ) I've added helper script (osmo-release.mk,
installed by recent libosmocore-dev) which attempts to automate as much as possible:

* treat library and non-library projects differently

* autogenerate debian/changelog

* automatically bump version

* cleanup TODO-RELEASE

* checks for missing *_LIBVERSION update

* automatically commit, sign and tag the result

Of course it might fail to do the right thing for multitude of reasons (incorrectly
filled TODO-RELEASE, missing tags, missing git-version-gen helper, weird versions in
debian/changelog etc) so nothing is pushed automatically. You're expected to inspect
the release commit and push it manually (don't forget to push the tag too!).

In general, it works: made libosmo-abis 0.4.0 and osmo-bts 0.6.0 releases using it.
The patches to make it available to other *osmo* projects are under review.

Now, if you've read that far, you must be really interested in making release for
some Osmocom project (or just really bored :) Either way, please do any of the following:

* read the wiki page linked above and see if anything unclear/poorly written/needs
corrections

* suggest further updates to release policy described in there

* review corresponding patches in gerrit

* suggest further automation step (ideally, as a patch to osmo-release.mk ;)

* try "make release" for one of the projects not mentioned above (if you have
sufficient rights to push tags to gerrit)

* have a look at recent libosmo-abis (>=0.4.0) and osmo-bts (>=0.6.0) and see if
anything is broken

N. B: release helper expects version to follow http://semver.org/ - this has been
raised in ML and no objections followed. Please adhere to it for all future versions.

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






From nhofmeyr at sysmocom.de  Sat Aug 26 18:23:05 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 26 Aug 2017 20:23:05 +0200
Subject: about merging deletion of checking-value-strings script from
 libosmocore
Message-ID: <20170826182305.GA4488@my.box>

I would have welcomed more patience in merging https://gerrit.osmocom.org/3685,
"Use value string check from osmo-ci" in libosmocore.
(the commit log of which fails to indicate removal of the script, btw)

Moving to the new repositories, I have enough loose ends flapping in the wind,
and dropping the script from libosmocore has added yet another distraction,
while not being necessary to start using the one from osmo-ci.

Max clearly posted "N. B: this should be merged last, after all the repos
converted to check script from osmo-ci." -- which is not the case for the new
repositores split from openbsc.git.

In osmo-msc I have >50 patches waiting to be merged. The timing could hardly
have been worse, luckily only a few gerrit builds are affected. Will try to
sort out merging of the patches without needing a rebase and >50 rebuilds.

Thanks for you attention :)

~N

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

From nhofmeyr at sysmocom.de  Wed Aug 30 11:53:21 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 30 Aug 2017 13:53:21 +0200
Subject: jenkins build slaves: Rationale for some builds in docker vs.
 some not?
In-Reply-To: <236AF04A-5604-486A-ABE8-7020CA05046D@freyther.de>
References: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
 <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>
 <20170827142852.GB2805@my.box>
 <236AF04A-5604-486A-ABE8-7020CA05046D@freyther.de>
Message-ID: <20170830115321.GA2050@my.box>

On Wed, Aug 30, 2017 at 01:12:06AM +0200, Holger Freyther wrote:
> In the sysmocom system-images I played with the XML "template" and the java
> client to create/update jobs but Lynxis found that yaml DSL to describe jobs
> more easily and I think we could explore that. We could have one repository
> will all the jobs and run that to populate jenkins. E.g. this even enforces
> standards like discarding old builds (we don't run on turing tape after all).

That sounds excellent! Setting up jobs on the web ui can be quite cumbersome
and documenting it is even worse... 

Yet someone needs to setup the yaml DSL.
(Sounds like a job for dr.blobb, but haven't heard anything in a while)

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

From msuraev at sysmocom.de  Mon Aug 28 12:38:43 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 28 Aug 2017 14:38:43 +0200
Subject: RFC: use git-version-gen from gnulib
Message-ID: <95a6f116-50f5-a455-9bb3-24377c90b3c4@sysmocom.de>

Hi.

I'd like to propose to switch from local (unmaintained?) copy of git-version-gen
script and use it directly from upstream gnulib package. It's available pretty-much
everywhere (including ancient Debian which we support for nightly). It's also
available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/

It doesn't feel right to use copy-pasted code when we could offload the maintenance
work to packaging/dependency tools.

What do you think? Please contribute to https://osmocom.org/issues/2467 which I've
created to track this RFC.

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






From holger at freyther.de  Tue Aug 29 23:12:06 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 30 Aug 2017 01:12:06 +0200
Subject: jenkins build slaves: Rationale for some builds in docker vs.
 some not?
In-Reply-To: <20170827142852.GB2805@my.box>
References: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
 <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>
 <20170827142852.GB2805@my.box>
Message-ID: <236AF04A-5604-486A-ABE8-7020CA05046D@freyther.de>


> On 27. Aug 2017, at 16:28, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 

Hey!


> Unfortunately, documenting the jenkins setup while tweaking it is time
> consuming and tends to become outdated quickly. I think documenting our entire
> setup is nontrivial. I did so for the osmo-gsm-tester jobs, which takes up a
> large part of the osmo-gsm-tester manual. We need to find a feasible balance of
> detail, which I guess should be rather coarse. Numerous documentation and wiki
> restructuring tasks for Osmocom components themselves are continuously pending
> and IMHO higher in priority.

Documentation is always prone to being outdated (leave alone some random notes
in a wiki...) and it takes a lot of effort to keep it updated. What I think works
is to automate as much as possible. This allows someone to _read_ the log and
try things.

In the sysmocom system-images I played with the XML "template" and the java
client to create/update jobs but Lynxis found that yaml DSL to describe jobs
more easily and I think we could explore that. We could have one repository
will all the jobs and run that to populate jenkins. E.g. this even enforces
standards like discarding old builds (we don't run on turing tape after all).


cheers
	holger

From nhofmeyr at sysmocom.de  Sun Aug 27 14:28:52 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 27 Aug 2017 16:28:52 +0200
Subject: jenkins build slaves: Rationale for some builds in docker vs.
 some not?
In-Reply-To: <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>
References: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
 <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>
Message-ID: <20170827142852.GB2805@my.box>

On Fri, Aug 25, 2017 at 08:37:12PM +0800, Holger Freyther wrote:
> I can't comment if osmo-msc-gerrit is using a different container than
> other builds.

Until recently only OpenBSC and OpenBSC-gerrit were using docker.
osmo-msc and osmo-msc-gerrit were copied from (one of) those, hence those are
also using docker. osmo-{bsc,mgw,sgsn} don't exist yet but could do the same.

They (will) use the same docker image.

The mentioned vty tests port conflicts are related to the build matrix
containing eight different builds, which can be parallelized by using the
docker container; and also allows building separate patches in parrallel.

Unfortunately, documenting the jenkins setup while tweaking it is time
consuming and tends to become outdated quickly. I think documenting our entire
setup is nontrivial. I did so for the osmo-gsm-tester jobs, which takes up a
large part of the osmo-gsm-tester manual. We need to find a feasible balance of
detail, which I guess should be rather coarse. Numerous documentation and wiki
restructuring tasks for Osmocom components themselves are continuously pending
and IMHO higher in priority.

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

From nhofmeyr at sysmocom.de  Sun Aug 27 14:57:46 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 27 Aug 2017 16:57:46 +0200
Subject: osmocom.org redmine unable to register new users?
Message-ID: <20170827145746.GC2805@my.box>

I notice that our osmocom.org redmine no longer seems to send out registration mails.
See https://osmocom.org/issues/2466

~N

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

From nhofmeyr at sysmocom.de  Sun Aug 27 14:08:46 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 27 Aug 2017 16:08:46 +0200
Subject: osmo-msc patch series from openbsc.git
In-Reply-To: <20170824205114.acyetlactkzymmey@nataraja>
References: <20170824174027.GA1997@ass40.sysmocom.de>
 <20170824205114.acyetlactkzymmey@nataraja>
Message-ID: <20170827140846.GA2805@my.box>

On Thu, Aug 24, 2017 at 10:51:14PM +0200, Harald Welte wrote:
> On Thu, Aug 24, 2017 at 07:40:27PM +0200, Neels Hofmeyr wrote:
> > I rebased the recent openbsc.git patches to osmo-msc.git and am submitting
> > all of them on gerrit, to make sure each passes the tests. Since they are
> > already accepted on openbsc.git, I'll also directly +2 and merge them.
> 
> Thanks, that's great.
> 
> How to proceed with the split?  Should we review patches that are failing (-V),
> or should we wait until they actually build?

There have been some odd failures that seem related to build host / docker
issues rather than the code itself: only patches in the middle failed,
subsequent ones succeeded, which indicates sporadic failure.

In the end I decided to check that the final result of all openbsc.git news
added to osmo-msc.git builds, and then merged all of the patches to osmo-msc
master ... for the benefit of getting on with the actual new patches.

About those, there are still some without-iu build errors, odd "Broken Pipe"
failures and vty tests failures. I'm battling gerrit and jenkins windmills to
finally verify them.

~N

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

From msuraev at sysmocom.de  Tue Aug 29 10:00:26 2017
From: msuraev at sysmocom.de (Max)
Date: Tue, 29 Aug 2017 12:00:26 +0200
Subject: BSC+BTS SI + LAPD validation, TTCN-3 Testsuite
In-Reply-To: <20170824205009.bfcot53niv34dzab@nataraja>
References: <20170719184354.n7dvcyp3kif7mctz@nataraja>
 <2680b34c-b1cb-f49e-b81f-f11dba62fdbc@sysmocom.de>
 <20170824205009.bfcot53niv34dzab@nataraja>
Message-ID: <6e1a3cf6-2478-b69d-a413-5257d56a212c@sysmocom.de>

On 24.08.2017 22:50, Harald Welte wrote:
>
> sure, but I think the bigger topic at the moment is that people have to get a
> working TTCN-3 setup on their system (I'm using debian 9 which has the compiler
> included) and understand how to write TTCN-3 code.  gerrit is probably a rather
> small step in comparison.

Sure. In a meantime - shall I send some bikeshedding patches to ML or wait until it's
added to gerrit?

> I'm using 6.2.0 as shipped with debian 9 (which you can see from the docker-playground.git)

Yepp, worked for me too, 5.5.1 I've got was simply too old. I've updated the wiki.

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






From msuraev at sysmocom.de  Thu Aug 31 10:12:30 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 31 Aug 2017 12:12:30 +0200
Subject: [PATCH] test/common.sh: fix typo in gapk binary location
In-Reply-To: <20170830085034.482-1-axilirator@gmail.com>
References: <20170830085034.482-1-axilirator@gmail.com>
Message-ID: <5ba93448-35f7-ebaa-99a0-d1fc893a927d@sysmocom.de>

Shall we add gapk to gerrit to facilitate contributions?

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






From 246tnt at gmail.com  Thu Aug 31 11:06:51 2017
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 31 Aug 2017 13:06:51 +0200
Subject: [PATCH] test/common.sh: fix typo in gapk binary location
In-Reply-To: <20170830085034.482-1-axilirator@gmail.com>
References: <20170830085034.482-1-axilirator@gmail.com>
Message-ID: <CAHL+j09ezU8=jFv0OJi5znb5B9RibG3MDRqg93iRTqY1wH2Fqw@mail.gmail.com>

applied

On Wed, Aug 30, 2017 at 10:50 AM, Vadim Yanitskiy <axilirator at gmail.com> wrote:
> ---
>  test/common.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/common.sh b/test/common.sh
> index 39cdd7d..591be3a 100644
> --- a/test/common.sh
> +++ b/test/common.sh
> @@ -4,7 +4,7 @@ REFDIR=./ref-files
>  if [ -f ../src/gapk ]; then
>         GAPK=../src/gapk
>  elif [ -f `which gapk` ]; then
> -       GAPK=`whiich gapk`
> +       GAPK=`which gapk`
>  else
>         exit 1
>  fi
> --
> 2.14.1
>


From laforge at gnumonks.org  Thu Aug 31 11:40:08 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 31 Aug 2017 13:40:08 +0200
Subject: RFC: use git-version-gen from gnulib
In-Reply-To: <95a6f116-50f5-a455-9bb3-24377c90b3c4@sysmocom.de>
References: <95a6f116-50f5-a455-9bb3-24377c90b3c4@sysmocom.de>
Message-ID: <20170831114008.io3mi2dx5hji6jns@nataraja>

Hi Max,

On Mon, Aug 28, 2017 at 02:38:43PM +0200, Max wrote:
> I'd like to propose to switch from local (unmaintained?) copy of git-version-gen
> script and use it directly from upstream gnulib package. It's available pretty-much
> everywhere (including ancient Debian which we support for nightly). It's also
> available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/

this sounds like yet another of the changes that you recently seem to like
to introduce to the build infrastructure which I don't like.

What kind of maintenance does something like git-version-gen require?  What
kind of bugs have we ever encountered in the copies that we keep in our repos?

Where is the *actual* benefit to us as developers and particularly to our users?

To me, this looks like the right thing in theory, but then in reality it will mean
all buildhosts/docker-images need to be updated, virtually every wiki page related
to building osmocom from source needs updates.  Projects like osmo-combo will need
to be updated.  Other people's dockerfiles or similar "recipes" need updates.

Is all of this an efficient use of our time?  Again, what bottom-line benefit does
this bring?  To me it just sounds like a change that is likely to create
fall-out and frustration down the line, for no obvious advantage.

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


From laforge at gnumonks.org  Thu Aug 31 11:36:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 31 Aug 2017 13:36:19 +0200
Subject: about merging deletion of checking-value-strings script from
 libosmocore
In-Reply-To: <20170826182305.GA4488@my.box>
References: <20170826182305.GA4488@my.box>
Message-ID: <20170831113619.43pwu7sfvmdspy5v@nataraja>

Hi Neels,

On Sat, Aug 26, 2017 at 08:23:05PM +0200, Neels Hofmeyr wrote:
> I would have welcomed more patience in merging https://gerrit.osmocom.org/3685,
> "Use value string check from osmo-ci" in libosmocore.
> (the commit log of which fails to indicate removal of the script, btw)

My apologies.

I'm absolutely *not* in favor of quite a number of the recent changes that
affect the build dependencies, including the introduction of the bumpversion
dependency, the move of the value string script, etc.

The big problem is that such changes are often done *before* there is any discussion
about whether the community actually thinks this is a good change, and hence
I'm facing the decision: "Get over my reservations and make use of the
work that has been done" vs.  "reject more of those changes".

I think in hindsight, I have regretted a lot of those instances where I
merged them despite my reservations.  Your experience with fall-out from
this particular change is one more reason to lean more on the "reject"
side from now on.

Also, if anyone else is planning changes to the build systems /
infrastructure / build-time dependencies / ...:  Please discuss *before*
you invest time in doing something that will then rather likely be
rejected.

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)