From keith at rhizomatica.org  Fri Sep  1 12:44:12 2017
From: keith at rhizomatica.org (Keith Whyte)
Date: Fri, 1 Sep 2017 14:44:12 +0200
Subject: minor annoyance - file blank on git.osmocom.org
Message-ID: <ac3541da-68c5-900c-73f3-1dc4da8f113a@rhizomatica.org>

Does everyone else also see this as an empty file?

http://git.osmocom.org/libosmocore/tree/src/codec/gsm690.c

The plain text version looks fine.


k/




From laforge at gnumonks.org  Fri Sep  1 13:02:55 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 1 Sep 2017 15:02:55 +0200
Subject: minor annoyance - file blank on git.osmocom.org
In-Reply-To: <ac3541da-68c5-900c-73f3-1dc4da8f113a@rhizomatica.org>
References: <ac3541da-68c5-900c-73f3-1dc4da8f113a@rhizomatica.org>
Message-ID: <20170901130255.273oqydywaiusavj@nataraja>

On Fri, Sep 01, 2017 at 02:44:12PM +0200, Keith Whyte wrote:
> Does everyone else also see this as an empty file?
> http://git.osmocom.org/libosmocore/tree/src/codec/gsm690.c
> The plain text version looks fine.

Yes, looks like a cgit rendering bug :/

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


From msuraev at sysmocom.de  Fri Sep  1 14:50:05 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 1 Sep 2017 16:50:05 +0200
Subject: RFC: use git-version-gen from gnulib
In-Reply-To: <20170831114008.io3mi2dx5hji6jns@nataraja>
References: <95a6f116-50f5-a455-9bb3-24377c90b3c4@sysmocom.de>
 <20170831114008.io3mi2dx5hji6jns@nataraja>
Message-ID: <4d4c0b1f-2181-3d7f-b8d4-3b8831537bb0@sysmocom.de>

You're right about extra efforts.  It still doesn't feel right to use copy-pasted
code precisely because we can't easily answer to those questions about bugs we have
in our outdated copy. Nevertheless, I see your point, thanks for feedback.

On 31.08.2017 13:40, Harald Welte wrote:
>
> 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?

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






From nhofmeyr at sysmocom.de  Fri Sep  1 22:45:47 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 2 Sep 2017 00:45:47 +0200
Subject: about merging deletion of checking-value-strings script from
 libosmocore
In-Reply-To: <20170831113619.43pwu7sfvmdspy5v@nataraja>
References: <20170826182305.GA4488@my.box>
 <20170831113619.43pwu7sfvmdspy5v@nataraja>
Message-ID: <20170901224547.GA2278@my.box>

On Thu, Aug 31, 2017 at 01:36:19PM +0200, Harald Welte wrote:
> 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.

I agree.

A practical problem can be that individuals may be too busy to read all the
patches pending on gerrit. Meaning that problems one of us would notice can
easily slip by. It doesn't necessarily help to wait more...

Seems that the only way is to tend to be dismissive. In the recent past I've
caused annoyance by being too dismissive / criticizing. But I see it as a
normal and necessary process, and ideally it shouldn't discourage/annoy anyone.

In this instance I was not aware of the change until it was already merged, and
I would have voted for keeping the value string checking script in libosmocore,
close to where the struct value_string originates. I placed it there on
purpose. Any job building code with value_strings in it by definition has a
libosmocore close by, be it in our jenkins.osmocom.org builds *or anywhere
else*. osmo-ci is especially for our own jenkins; other entities wanting to
check value strings now would need osmo-ci in addition to libosmocore.
Admittedly I'm not aware of any such other entities, so it's not a practical
problem to have it in osmo-ci and, now that it's done, probably not worth it to
move it back ...  unfortunately ;)

~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/20170902/68e5a8de/attachment.bin>

From nhofmeyr at sysmocom.de  Sat Sep  2 01:12:50 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 2 Sep 2017 03:12:50 +0200
Subject: minor annoyance - file blank on git.osmocom.org
In-Reply-To: <20170901130255.273oqydywaiusavj@nataraja>
References: <ac3541da-68c5-900c-73f3-1dc4da8f113a@rhizomatica.org>
 <20170901130255.273oqydywaiusavj@nataraja>
Message-ID: <20170902011250.GD2278@my.box>

On Fri, Sep 01, 2017 at 03:02:55PM +0200, Harald Welte wrote:
> On Fri, Sep 01, 2017 at 02:44:12PM +0200, Keith Whyte wrote:
> > Does everyone else also see this as an empty file?
> > http://git.osmocom.org/libosmocore/tree/src/codec/gsm690.c
> > The plain text version looks fine.
> 
> Yes, looks like a cgit rendering bug :/

I've recently noticed the same bug here: 
https://cgit.osmocom.org/openbsc/tree/openbsc/src/osmo-bsc/osmo_bsc_bssap.c

BTW, just now I only got long waits and then "502 Bad Gateway" on
git.osmocom.org ... in a separate mail.

~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/20170902/36c2954c/attachment.bin>

From nhofmeyr at sysmocom.de  Sat Sep  2 01:14:33 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 2 Sep 2017 03:14:33 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
Message-ID: <20170902011433.GE2278@my.box>

Just now I only got long waits and then "502 Bad Gateway" on
git.osmocom.org ... the cgit ezjail hit its root partition limit.  I had to
re-figure out what I did last time, tried to find ezjail-admin options until
finally I ended up back in zfs and started remembering... I increased the zfs
quota for the cgit jail from 10G to 15G. Now it's working again.

For the record, resizing an ezjail goes like
# zfs list
# zfs get quota tank/jails/cgit
# zfs set quota=15G tank/jails/cgit
(so next time I can find it in my mail archive, and I guess it should go in a
wiki somewhere. On osmocom.org?)

Last time it was the jenkins jail hitting disc limits. Then I said
"We should probably set a refquota so that the live file system's quota is
somewhat independent from the quota used for snapshots."
I see the jenkins jail now has a 40G refquota, but the others seem not to.
How does it work, set a huge quota to allow space for snapshots, and limit the
fs itself by a refquota?

~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/20170902/72901bcb/attachment.bin>

From hfreyther at sysmocom.de  Sat Sep  2 07:40:58 2017
From: hfreyther at sysmocom.de (Holger Freyther)
Date: Sat, 2 Sep 2017 09:40:58 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170902011433.GE2278@my.box>
References: <20170902011433.GE2278@my.box>
Message-ID: <7EF03B84-0BBE-435E-A0D2-D5D6F644DC3D@sysmocom.de>


> On 2. Sep 2017, at 03:14, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:



Hi!


> Just now I only got long waits and then "502 Bad Gateway" on
> git.osmocom.org ... the cgit ezjail hit its root partition limit.  I had to
> re-figure out what I did last time, tried to find ezjail-admin options until
> finally I ended up back in zfs and started remembering... I increased the zfs
> quota for the cgit jail from 10G to 15G. Now it's working again.

What takes 10G? The actual git repos are mounted RO and should not consume
any space. The only thing that should take space is the log and the cgit
cache.


> Last time it was the jenkins jail hitting disc limits. Then I said
> "We should probably set a refquota so that the live file system's quota is
> somewhat independent from the quota used for snapshots."
> I see the jenkins jail now has a 40G refquota, but the others seem not to.
> How does it work, set a huge quota to allow space for snapshots, and limit the
> fs itself by a refquota?

quota -> refquota is a good thing. Let's do it. I think we ran into this
not because the actual jail size was > 10GB but the cache was re-written
over the last weeks.


holger



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



From laforge at gnumonks.org  Sat Sep  2 08:03:24 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 2 Sep 2017 10:03:24 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170902011433.GE2278@my.box>
References: <20170902011433.GE2278@my.box>
Message-ID: <20170902080324.akjpklf5wex7mgdd@nataraja>

Hi Neels,

thanks for looking into this.

On Sat, Sep 02, 2017 at 03:14:33AM +0200, Neels Hofmeyr wrote:
> Just now I only got long waits and then "502 Bad Gateway" on
> git.osmocom.org ... the cgit ezjail hit its root partition limit.  I had to
> re-figure out what I did last time, tried to find ezjail-admin options until
> finally I ended up back in zfs and started remembering... I increased the zfs
> quota for the cgit jail from 10G to 15G. Now it's working again.

the question is why does it need that much quota?  Right now I can see
that it only uses only 2.1GB on disk:

root at cgit:/ # df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
tank/jails/cgit    8.4G    2.1G    6.3G    25%    /

Did you (or somebody else) clear the cgit cache (it's currently 1.8GB)?
The cache is limited in number of files (10k), not in size of those
files by (cgitrc 'cache-size' attribute).

What has grown beyond that existing 10GB limit?

> For the record, resizing an ezjail goes like
> # zfs list
> # zfs get quota tank/jails/cgit
> # zfs set quota=15G tank/jails/cgit
> (so next time I can find it in my mail archive, and I guess it should go in a
> wiki somewhere. On osmocom.org?)

sure, that's why we have the http://osmocom.org/projects/osmocom-servers
redmine for, I guess.

> Last time it was the jenkins jail hitting disc limits. Then I said
> "We should probably set a refquota so that the live file system's quota is
> somewhat independent from the quota used for snapshots."

when are snapshots used?

-- 
- 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  Sat Sep  2 14:30:09 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sat,  2 Sep 2017 21:30:09 +0700
Subject: [PATCH 1/2] pq_alsa.c: handle output buffer underrun
Message-ID: <20170902143009.14011-1-axilirator@gmail.com>

On some systems the ALSA output buffer is pretty big, and
if the audio samples are not being passed into the buffer
quickly enough, it becomes starved for data, resulting
in an error called underrun.

Previously, when it happenned, GAPK used to stop processing
with the following message (where X is a random number):

[+] PQ: Adding ALSA output (dev='default', blk_len=320)
[!] pq_execute(): abort, item returned -1
[+] Processed X frames

According to the ALSA documentation, the pcm_handle
changes its state when the problem happens, and should
be recovered using the snd_pcm_prepare() call. This change
actually does that.
---
 src/pq_alsa.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/pq_alsa.c b/src/pq_alsa.c
index 9cee426..a3435dd 100644
--- a/src/pq_alsa.c
+++ b/src/pq_alsa.c
@@ -57,7 +57,15 @@ pq_cb_alsa_output(void *_state, uint8_t *out, const uint8_t *in, unsigned int in
 	struct pq_state_alsa *state = _state;
 	unsigned int num_samples = in_len/2;
 	int rv;
+
 	rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+	if (rv == -EPIPE) {
+		/* Recover from buffer underrun */
+		snd_pcm_prepare(state->pcm_handle);
+		/* Send a new sample again */
+		rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+	}
+
 	return rv == num_samples ? 0 : -1;
 }
 
-- 
2.14.1


>From 8f1b0a9bf966cd561b10d2d33c6a47dd02e17dcf Mon Sep 17 00:00:00 2001
From: Vadim Yanitskiy <axilirator at gmail.com>
Date: Sat, 2 Sep 2017 18:02:45 +0700
Subject: [PATCH 2/2] pq_alsa.c: print error message if device init fails
To: openbsc at lists.osmocom.org
Cc: 246tnt at gmail.com,
    laforge at gnumonks.org,
    axilirator at gmail.com

---
 src/pq_alsa.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/pq_alsa.c b/src/pq_alsa.c
index a3435dd..cad76ca 100644
--- a/src/pq_alsa.c
+++ b/src/pq_alsa.c
@@ -85,13 +85,16 @@ pq_queue_alsa_op(struct pq *pq, const char *alsa_dev, unsigned int blk_len, int
 	int rc = -1;
 
 	state = calloc(1, sizeof(struct pq_state_alsa));
-	if (!state)
-		return -ENOMEM;
+	if (!state) {
+		rc = -ENOMEM;
+		goto out_print;
+	}
 
 	rc = snd_pcm_open(&state->pcm_handle, alsa_dev,
 			  in_out_n ? SND_PCM_STREAM_CAPTURE : SND_PCM_STREAM_PLAYBACK, 0);
 	if (rc < 0)
-		return rc;
+		goto out_print;
+
 	state->blk_len = blk_len;
 
 	rc = snd_pcm_hw_params_malloc(&hw_params);
@@ -143,6 +146,9 @@ out_free_par:
 out_close:
 	snd_pcm_close(state->pcm_handle);
 	free(state);
+out_print:
+	fprintf(stderr, "[!] Couldn't init ALSA device '%s': %s\n",
+		alsa_dev, snd_strerror(rc));
 	return rc;
 }
 
-- 
2.14.1



From axilirator at gmail.com  Sat Sep  2 14:34:02 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sat,  2 Sep 2017 21:34:02 +0700
Subject: [PATCH 1/2] pq_alsa.c: handle output buffer underrun
Message-ID: <20170902143403.14185-1-axilirator@gmail.com>

On some systems the ALSA output buffer is pretty big, and
if the audio samples are not being passed into the buffer
quickly enough, it becomes starved for data, resulting
in an error called underrun.

Previously, when it happenned, GAPK used to stop processing
with the following message (where X is a random number):

[+] PQ: Adding ALSA output (dev='default', blk_len=320)
[!] pq_execute(): abort, item returned -1
[+] Processed X frames

According to the ALSA documentation, the pcm_handle
changes its state when the problem happens, and should
be recovered using the snd_pcm_prepare() call. This change
actually does that.
---
 src/pq_alsa.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/pq_alsa.c b/src/pq_alsa.c
index 9cee426..a3435dd 100644
--- a/src/pq_alsa.c
+++ b/src/pq_alsa.c
@@ -57,7 +57,15 @@ pq_cb_alsa_output(void *_state, uint8_t *out, const uint8_t *in, unsigned int in
 	struct pq_state_alsa *state = _state;
 	unsigned int num_samples = in_len/2;
 	int rv;
+
 	rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+	if (rv == -EPIPE) {
+		/* Recover from buffer underrun */
+		snd_pcm_prepare(state->pcm_handle);
+		/* Send a new sample again */
+		rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+	}
+
 	return rv == num_samples ? 0 : -1;
 }
 
-- 
2.14.1


From axilirator at gmail.com  Sat Sep  2 14:34:03 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sat,  2 Sep 2017 21:34:03 +0700
Subject: [PATCH 2/2] pq_alsa.c: print error message if device init fails
In-Reply-To: <20170902143403.14185-1-axilirator@gmail.com>
References: <20170902143403.14185-1-axilirator@gmail.com>
Message-ID: <20170902143403.14185-2-axilirator@gmail.com>

---
 src/pq_alsa.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/pq_alsa.c b/src/pq_alsa.c
index a3435dd..cad76ca 100644
--- a/src/pq_alsa.c
+++ b/src/pq_alsa.c
@@ -85,13 +85,16 @@ pq_queue_alsa_op(struct pq *pq, const char *alsa_dev, unsigned int blk_len, int
 	int rc = -1;
 
 	state = calloc(1, sizeof(struct pq_state_alsa));
-	if (!state)
-		return -ENOMEM;
+	if (!state) {
+		rc = -ENOMEM;
+		goto out_print;
+	}
 
 	rc = snd_pcm_open(&state->pcm_handle, alsa_dev,
 			  in_out_n ? SND_PCM_STREAM_CAPTURE : SND_PCM_STREAM_PLAYBACK, 0);
 	if (rc < 0)
-		return rc;
+		goto out_print;
+
 	state->blk_len = blk_len;
 
 	rc = snd_pcm_hw_params_malloc(&hw_params);
@@ -143,6 +146,9 @@ out_free_par:
 out_close:
 	snd_pcm_close(state->pcm_handle);
 	free(state);
+out_print:
+	fprintf(stderr, "[!] Couldn't init ALSA device '%s': %s\n",
+		alsa_dev, snd_strerror(rc));
 	return rc;
 }
 
-- 
2.14.1


From laforge at gnumonks.org  Sat Sep  2 15:04:22 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 2 Sep 2017 17:04:22 +0200
Subject: [PATCH 1/2] pq_alsa.c: handle output buffer underrun
In-Reply-To: <20170902143403.14185-1-axilirator@gmail.com>
References: <20170902143403.14185-1-axilirator@gmail.com>
Message-ID: <20170902150422.aaw3ezpfsz72v3ia@nataraja>

Thanks,

both applied.

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


From alexander.chemeris at gmail.com  Sat Sep  2 21:11:04 2017
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sun, 3 Sep 2017 00:11:04 +0300
Subject: OpenBSC USSD external application
In-Reply-To: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>
References: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>
Message-ID: <CABmJbFUEn-RjHbTHMcgBZdQ2hZZtn-+Oic8RC2+QRrC7R_jbzg@mail.gmail.com>

Hi Rowan,

A more recent version of this work is a part of the
fairwaves/master-rebase branch. It has implementation of exporting
USSD (and any other SS for that matter) over a SUP socket and an
external utility to decode/encode them and convert to/from SIP+XML
similar to defined in the IMS standard.

We're currently using this code to implement external USSD services
like a balance check from a billing system and also to forward SS and
USSD to MAP/Sigtran. So I think the code should work well for you.

If you find this code useful, we would greatly appreciate any help in
merging this code into master. We intend to eventually merge this into
master, but it requires some cleanup before it could be submitted for
a review and given it's not a simple small change we've never had
enough time to do that so far :(

On Wed, Aug 30, 2017 at 10:59 PM, Rowan Phipps
<phippsr at cs.washington.edu> wrote:
> 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



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


From nhofmeyr at sysmocom.de  Sun Sep  3 00:08:33 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 3 Sep 2017 02:08:33 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170902080324.akjpklf5wex7mgdd@nataraja>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja>
Message-ID: <20170903000833.GB15743@my.box>

On Sat, Sep 02, 2017 at 10:03:24AM +0200, Harald Welte wrote:
> the question is why does it need that much quota?  Right now I can see
> that it only uses only 2.1GB on disk:
> 
> root at cgit:/ # df -h
> Filesystem         Size    Used   Avail Capacity  Mounted on
> tank/jails/cgit    8.4G    2.1G    6.3G    25%    /

> What has grown beyond that existing 10GB limit?

When this happened, the root fs was on 4.1G, with a 'quota' of 10G, i.e.
probably ~6G taken up by snapshots. Something must have shrunk since then.

I've now changed to refquota=5G (so the root fs can be up to 5G, chose 5 since
I saw it hit 4G) and removed the quota (i.e. the snapshots will not cause us to
limit disk space on the jail).

> Did you (or somebody else) clear the cgit cache (it's currently 1.8GB)?

Maybe someone cleared it and that's why we have more space now?
Wasn't me.
Looking at /var/chache/cgit it doesn't look like it was cleared.

I now see

NAME                               USED  AVAIL  REFER  MOUNTPOINT
tank/jails/cgit                   8.87G  3.25G  1.75G  /usr/jails/cgit

i.e. 1.75G taken up by root fs, ~7 more G taken up by snapshots.

It seems a max of 5G is way beyond the current 1.75G, but I can't tell
what grew the root fs to 4G ... I'm happy to accept any other value.

Maybe it was the cache that grew this large, and maybe the recent cgit
rendering failures were due to hitting disc space limits? ... no,
I just cleared the cgit cache and "my" file still renders empty.

(cleared by
cd /var/cache
mkdir not_cgit
mv cgit/* not_cgit/
and then testing whether it still works,
and it seems to work.
So I'm now doing 'rm -rf not_cgit'.
For the record
root at cgit:/var/cache # du -hs not_cgit/
1.5G	not_cgit/
root at cgit:/var/cache # df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
tank/jails/cgit    5.0G    1.9G    3.1G    38%    /

root at cgit:/var/cache # rm -rf not_cgit/
root at cgit:/var/cache # df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
tank/jails/cgit    5.0G    368M    4.6G     7%    /

Seems like we can shrink refquota considerably, and what grew to 4G remains a
mystery.)

> when are snapshots used?

I'm not entirely sure. Holger?

> > For the record, resizing an ezjail goes like
[...]
> 
> sure, that's why we have the http://osmocom.org/projects/osmocom-servers
> redmine for, I guess.

Added an initial https://osmocom.org/projects/osmocom-servers/wiki/Osmocomorg_Web_Servers

~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/20170903/bac581d8/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Sep  3 03:39:12 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 3 Sep 2017 05:39:12 +0200
Subject: release process review
Message-ID: <20170903033912.GC15743@my.box>

I'm reading through https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
and noting things as I go...


> library vs. non-library projects

This is not a thing and should disappear from the release process. We have many
projects that build programs as well as install libraries.

I see this is about the *_LIBVERSION, right? ... maybe we can say something
like "adjust *_LIBVERSION (not required if the project does not install any
libraries)" ?


> "adhere to RERO better"

RERO -- had to look it up, Eric's quote of "Release early, release often" :)

And lol, the PDF link there refers to papers written basically by the "private
club" of my former colleagues at the Subversion project :) Eric, Justin, Hyrum,
all Subversion folks.

Interesting side fact is that Subversion has never had time-based releases,
despite one hackathon vote accepting that as policy.

One detail though is that technically we do radical Release Early, because all
of our code is on public git immediately. I'm not sure that Eric's quote refers
to actual glorified "stable" releases, I understood as "make available early".

Anyhow, this paragraph seems unrelated to the tagging process, could be related
to the time-based package feed releases (see below).


> "Proposed policy:"

We already have what I'd call a loose bunch of accepted policies after
OsmoDevCon 2017 and mails following it.

It is first of all important to note a profound difference between two things
we're aming for: providing a package feed with a global glorified state
(time based), and the individual version tags in each git (feature based).

With this in mind, recall the thread starting with:
https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html

Let me summarize:

- "Global" package feeds

We are planning to provide package feeds in a time-based fashion, by pinning
code states and providing built packages. This is mostly a service to our user
base, so that they can easily communicate and update to versions.

They are to be called osmocom-cell-net / OsmocomCellNet and will have
year+month based version numbers, YY.MM like 17.03 17.06 17.09 17.12
and, quote:
> > I suggest that we follow a regular release schedule of: at the beginning
> > of March, June, September and December.  (so that we don't need to roll a
> > release during/right after the festive season, i.e. not on 1st January)

At this point we might aim at an OsmocomCellNet-17.12 package feed to be out
on 1st of December.

These feeds will not wait for features or code-freeze ahead. We will simply pin
a certain point in time. If serious bugs arise we might choose to adjust, but
the advice is to then just use the previous / wait three months for the next.


- Individual git tree version numbers

In contrast to the global package feeds, each git tree has its own local
version with a git version tag.  This does not follow the year+month scheme but
rather "1.2.3" major.minor.patch.

Compatibility is reflected in these version numbers, i.e. big incompatibilities
require a major version bump, mere internal fixes can bump the patch version.

(So far I understood the wiki page "Make a new release" referring to only these
individual git repository versions, but we must clarify the two different
concepts on that page and at least refer to a package feed wiki page.)

How do the global package feeds correspond to individual major-minor-patch
versions? For each of the global feeds, we should make sure that the precise
git trees that are packaged correspond 1:1 to local git version tags. I.e.
before we roll out a package feed, we make local version number tags to glorify
the current master branch in each repository (bumping versions according to
compatibility considerations) and actually use those precise version tags to
mark the state that will go out in the OsmocomCellNet-YY.MM feed.

So, while the time-based package feeds will be one driving force behind bumping
individual version numbers, we are technically still able to mark new local
version tags here and there independently from the time-based feeds.


To avoid confusion, rather than talking of "release" it could help to talk of
"package feed" versus "git version tag".



> master branch is expected to depend on latest master branches of depended-upon projects

The master branch HEADs are in constant flux, the requirement that each master
works with the other latest masters is more of a daily development requirement
enforced by our gerrit +V builds. For feeds and tags, we should not even
mention "master branch" anywhere. Rather, the entire process *must* refer to
specific version tags *everywhere*.

But I'm not entirely sure how to put it. It is possible that we already have
libosmo-foo 1.2.3 out, but osmo-bar also still builds fine with libosmo-foo
1.2.1.

I guess all we need is that configure.ac version requirements are accurate. We
will not always have to depend on the latest version number that's out, and if
older ones work, ./configure should *not* require the most recent version.

How to verify? I guess a version tag of osmo-X must verify
- that building with the precise minimal versions requested in configure.ac
  works
AND
- that building with the currently latest tagged version of each depended-upon
  project also works
AND
- that building with each intermittent version of each dependency also works???

That's turning out rather complex ... maybe verifying with only the oldest
required and the latest tagged versions is enough?


> make release of depended-upon projects if necessary before making non-library project release

So, are you saying, if foo needs bar which needs baz, releasing foo requires
also releasing bar, in turn needing a release of baz first?
... "if necessary" :)

To spell it out: this is not necessarily required; only when foo is using new
API of bar that is not available in a tagged version of bar yet are we forced
to make a version tag of bar and depend on it.

BTW, this is implicit by "it must build with the version requested by
configure.ac".

The text on that wiki page before your edits did say exactly that:
>> As soon as a feature is added to one Osmocom project that is needed for
>> another dependent project to compile, we should tag at least a minor-revision
>> bump in the depended-upon project and require it in the depend[ent] project's
>> configure.ac.
IMHO that's still exactly what it should say there.

For the global package feed we choose to tag a new version everywhere so that
we can pinpoint the current state that we want to glorify, but it is not
strictly required for a local version bump to also tag depended-upon gits.

> make sure that we have correct version dependencies before making non-library project release

IOW: make sure configure.ac reflects the version number of depended-upon gits
that are the minimum requirement to build. (scratch the "non-library")


Ok great, I've reviewed the first paragraph :)
Well, there was a lot of ground to cover, I hope I can do the rest less
verbosely...


> modify *_LIBVERSION in Makefile.am as necessary according to TODO-RELEASE file

would be good to clarify what you mean, e.g. by an example.

BTW, I find RANAP_LIBVERSION in osmo-iuh, ABIS_LIBVERSION and TRAU_LIBVERSION
in libosmo-abis and LEGACY_MGCP_LIBVERSION in osmo-mgw; that's all. Do we need
a lot more *_LIBVERSION everywhere, starting with libosmocore?

Also it would be good to embed this in the list of steps under "common steps"
... i.e. have just one list of steps standing out clearly; Ideally I can
start reading at the top and follow the steps one by one.

> The release helper is trying to be smart about it and prevent making new
> library release with non-empty TODO-RELEASE file if *_LIBVERSION is not
> adjusted beforehand.

Not sure I understand. I can either empty out TODO-RELEASE or change
*_LIBVERSION? If I modify *_LIBVERSION, I can make a release despite
TODO-RELEASE being nonempty?


> Use following guidelines when choosing release type:

I'd guess at
major: Previous API is no longer available, ABI has changed incompatibly.
minor: Additions to public API/ABI are present.
patch: API/ABI unchanged, internal changes only (like bugfixes).


> Deprecation policy

I think we should never remove deprecated functions unless it would cause us
inhumane pain to still include them. Dropping them would require a major
version bump.


> TODO-RELEASE file format and maintenance

would be excellent to provide an actual example there


> How to (re)tag a new release

Is tagging and re-tagging the same? Do I need to delete a tag first? A word to
clarify that would be good. Also, above it says re-sign, is that the same
thing?


Still unclear to me is, do I first tag a version, then do 'make release', and
then I need to re-tag / re-sign again?  A clear sequential list of steps and/or
a complete screen dump example would be very helpful to grok it.
[I remember OpenBSD CD sets having a complete listing of the default
installation in the CD booklet :) ]



Finally, I tried to call 'make release' but face these problems:

? make release
/bin/bash: bumpversion: command not found

? apt-cache search bumpversion
(no results)

Though I find 'bumpversion' on packages.debian.org, I am unable to install it
with 'apt-get'.
https://packages.debian.org/buster/bumpversion
It says "Packages / buster (testing) / devel / bumpversion"
...do I need to add "devel" to my apt sources somehow?

Do we really need bumpversion? Can I instead bump the version manually?


Also:

? make release
/bin/bash: bumpversion: command not found
osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.1.115-f7251) before proceeding..  Stop.

The intended version should be 1.0.2.
Is that because bumpversion is not available?
(Shouldn't it abort right away when bumpversion is missing?)

I tried to also tag a version first so that git-version-gen produces a clean
semver version:

? cat .version
1.0.2

but still get

? make release
/bin/bash: bumpversion: command not found
osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.2) before proceeding..  Stop.

(i.e. now it complains about "1.0.2" not being semver, which is inaccurate)

Can you document these pitfalls on the wiki as well, please?

~N


(P.S.: "first .. then" and "if .. then" ... it's almost always "then" with "e".)

-------------- 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/20170903/4099df67/attachment.bin>

From hfreyther at sysmocom.de  Sun Sep  3 07:34:39 2017
From: hfreyther at sysmocom.de (Holger Freyther)
Date: Sun, 3 Sep 2017 09:34:39 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170903000833.GB15743@my.box>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja> <20170903000833.GB15743@my.box>
Message-ID: <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>


> On 3. Sep 2017, at 02:08, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
>> when are snapshots used?
> 
> I'm not entirely sure. Holger?

They are automatically created by "zfsnap" and are a safety net for us
to allow a quick rollback or find older files.


holger

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



From laforge at gnumonks.org  Sun Sep  3 08:47:35 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 3 Sep 2017 10:47:35 +0200
Subject: release process review
In-Reply-To: <20170903033912.GC15743@my.box>
References: <20170903033912.GC15743@my.box>
Message-ID: <20170903084735.uflupnrsejuke54q@nataraja>

Hi Neels,

thanks for getting this discussion going.

On Sun, Sep 03, 2017 at 05:39:12AM +0200, Neels Hofmeyr wrote:

> (So far I understood the wiki page "Make a new release" referring to only these
> individual git repository versions, but we must clarify the two different
> concepts on that page and at least refer to a package feed wiki page.)

We should make sure not call anything "release" which is not an "osmocom
release" i.e. what oyu called the global package feeds such as
"OsmocomCellNet-17.12" which is the "17.12 release".  We should find
different wording for what the wiki page by Max describes in terms of
"tagging a new version in a single repository".

> To avoid confusion, rather than talking of "release" it could help to talk of
> "package feed" versus "git version tag".

See my comment above.  We should not talk about a "release" in any other
context than the time-based global ones.

> > master branch is expected to depend on latest master branches of depended-upon projects
> 
> The master branch HEADs are in constant flux, the requirement that each master
> works with the other latest masters is more of a daily development requirement
> enforced by our gerrit +V builds. For feeds and tags, we should not even
> mention "master branch" anywhere. Rather, the entire process *must* refer to
> specific version tags *everywhere*.

Full ACK.

> But I'm not entirely sure how to put it. It is possible that we already have
> libosmo-foo 1.2.3 out, but osmo-bar also still builds fine with libosmo-foo
> 1.2.1.
> 
> I guess all we need is that configure.ac version requirements are accurate. We
> will not always have to depend on the latest version number that's out, and if
> older ones work, ./configure should *not* require the most recent version.
> 
> How to verify? I guess a version tag of osmo-X must verify
> - that building with the precise minimal versions requested in configure.ac
>   works
> AND
> - that building with the currently latest tagged version of each depended-upon
>   project also works
> AND
> - that building with each intermittent version of each dependency also works???

Full ACK.

> That's turning out rather complex ... maybe verifying with only the oldest
> required and the latest tagged versions is enough?

Fine with me, but given that we only want to release once every three
months, I think a longer build job that iterates over a handful of
package versions is not unfeasible.  But certainly not the highest
priority.

> > make release of depended-upon projects if necessary before making non-library project release
> 
> So, are you saying, if foo needs bar which needs baz, releasing foo requires
> also releasing bar, in turn needing a release of baz first?
> ... "if necessary" :)
> 
> To spell it out: this is not necessarily required; only when foo is using new
> API of bar that is not available in a tagged version of bar yet are we forced
> to make a version tag of bar and depend on it.
> 
> BTW, this is implicit by "it must build with the version requested by
> configure.ac".

ACK.

> > Deprecation policy
> 
> I think we should never remove deprecated functions unless it would cause us
> inhumane pain to still include them. Dropping them would require a major
> version bump.

ACK.  Yes, so one could say "if we already bump the major version
[libversion], we can at that time optionally remove deprecated functions
if we think it significantly simplifies maintenance.

> Finally, I tried to call 'make release' but face these problems:
> 
> ? make release
> /bin/bash: bumpversion: command not found
> 
> ? apt-cache search bumpversion
> (no results)
> 
> Though I find 'bumpversion' on packages.debian.org, I am unable to install it
> with 'apt-get'.
> https://packages.debian.org/buster/bumpversion
> It says "Packages / buster (testing) / devel / bumpversion"
> ...do I need to add "devel" to my apt sources somehow?
> 
> Do we really need bumpversion? Can I instead bump the version manually?

I was also seriously surprised that we introduce a dependency that is
not even available in all our supported distributions.  In order to fix
the fall-out from the related changes, I had to add a 'bumpversion'
package build to the OBS for the nightly builds.

Hence I would also be very happy if we can see that dependency go again.

I don't like the tendency to add more dependencies to external packages
everywhere without a *very* strong reason.  Whether it's bumpversion or
gnulib or anything else like that.

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


From axilirator at gmail.com  Sun Sep  3 10:20:08 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sun,  3 Sep 2017 17:20:08 +0700
Subject: [PATCH] Fix BENCHMARK_STOP call for AMR and FR
Message-ID: <20170903102008.13414-1-axilirator@gmail.com>

---
 src/codec_amr.c | 4 ++--
 src/codec_fr.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/codec_amr.c b/src/codec_amr.c
index 4aae733..ca614ed 100644
--- a/src/codec_amr.c
+++ b/src/codec_amr.c
@@ -78,7 +78,7 @@ codec_amr_encode(void *state, uint8_t *cod, const uint8_t *pcm, unsigned int pcm
 		(unsigned char*) cod,
 		1
 	);
-	BENCHMARK_STOP(CODEC_EFR, 1);
+	BENCHMARK_STOP(CODEC_AMR, 1);
 
 	return rv;
 }
@@ -95,7 +95,7 @@ codec_amr_decode(void *state, uint8_t *pcm, const uint8_t *cod, unsigned int cod
 		(short *) pcm,
 		0
 	);
-	BENCHMARK_STOP(CODEC_EFR, 0);
+	BENCHMARK_STOP(CODEC_AMR, 0);
 
 	return PCM_CANON_LEN;
 }
diff --git a/src/codec_fr.c b/src/codec_fr.c
index 2ce44b4..917f34b 100644
--- a/src/codec_fr.c
+++ b/src/codec_fr.c
@@ -74,7 +74,7 @@ codec_fr_decode(void *state, uint8_t *pcm, const uint8_t *cod, unsigned int cod_
 	memcpy(cod_b, cod, FR_CANON_LEN);
 	BENCHMARK_START;
 	rc = gsm_decode(gh, (gsm_byte*)cod_b, (gsm_signal*)pcm);
-	BENCHMARK_STOP(CODEC_FR, 1);
+	BENCHMARK_STOP(CODEC_FR, 0);
 	if (rc < 0)
 		return rc;
 	return PCM_CANON_LEN;
-- 
2.14.1



From nhofmeyr at sysmocom.de  Sun Sep  3 15:25:27 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 3 Sep 2017 17:25:27 +0200
Subject: is OAP used?
Message-ID: <20170903152527.GA2499@my.box>

Some time back we implemented OAP to add an authentication layer to the IPA,
IIRC aimed at osmo-bsc_nat <-> MAP proxy to do milenage mutual auth.

Now the oap protocol code is in libosmocore, but the oap_client code is dup'ed
in osmo-{bsc,sgsn}.git. I would move the oap_client to libosmocore as well.

But all the while I'm not really certain that it is indeed being used.
osmo-sgsn has vty config for it, but I'm certain osmo-hlr doesn't bother
to implement the OAP server part (there's code but in #if 0).

osmo-bsc_nat remains, and possibly a GSUP counter part to the osmo-sgsn that
I'm not using (presumably the MAP proxy)?

Is anyone using OAP and the oap_client and is it worth the effort to keep it?
Can we / should we just drop OAP instead?

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/20170903/cc956e22/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Sep  3 15:39:54 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 3 Sep 2017 17:39:54 +0200
Subject: is OAP used?
In-Reply-To: <20170903152527.GA2499@my.box>
References: <20170903152527.GA2499@my.box>
Message-ID: <20170903153954.GA11242@my.box>

On Sun, Sep 03, 2017 at 05:25:27PM +0200, Neels Hofmeyr wrote:
> Now the oap protocol code is in libosmocore, but the oap_client code is dup'ed
> in osmo-{bsc,sgsn}.git. I would move the oap_client to libosmocore as well.

correction: the code is still there in osmo-bsc.git but that's just an
oversight during repository split: neither gsup_client nor oap are used
in that repository now.

It seems no-one can possibly use OAP, except using osmo-sgsn with said MAP
proxy.

~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/20170903/ee98ee3c/attachment.bin>

From laforge at gnumonks.org  Sun Sep  3 18:41:39 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 3 Sep 2017 20:41:39 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja>
 <20170903000833.GB15743@my.box>
 <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>
Message-ID: <20170903184139.m52dzicwso3vhr3d@nataraja>

Today the cgit jail quota again was exceeded and we saw 504 http errors
when accessing http://git.osmocom.org/

The reason was indeed that the cache grew to fill the entire 5GB quota.

I checked what kind of files were occupying that much cache: Unfortunately
more than 150 files each larger than 10MBytes as a result of cgit caching
the .tar.gz snapshots it creates.

Unfortunately the cgit cache can only be restricted in number of files, not
in terms of total size or "don't cache files larger than X".

As a workaround I disabled snapshot generation for now.  I presume there
was some crawler that generated snapshots for lots of commits.

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


From nhofmeyr at sysmocom.de  Mon Sep  4 03:13:07 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 4 Sep 2017 05:13:07 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170903184139.m52dzicwso3vhr3d@nataraja>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja>
 <20170903000833.GB15743@my.box>
 <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>
 <20170903184139.m52dzicwso3vhr3d@nataraja>
Message-ID: <20170904031307.GC11242@my.box>

On Sun, Sep 03, 2017 at 08:41:39PM +0200, Harald Welte wrote:
> I checked what kind of files were occupying that much cache: Unfortunately
> more than 150 files each larger than 10MBytes as a result of cgit caching
> the .tar.gz snapshots it creates.

> As a workaround I disabled snapshot generation for now.  I presume there
> was some crawler that generated snapshots for lots of commits.

Just to clarify ... those tar.gz snapshots are obviously not related to the zfs
snapshots we were talking about before, but some cgit specific mechanism.

~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/20170904/d5e24f3c/attachment.bin>

From hfreyther at sysmocom.de  Mon Sep  4 20:02:43 2017
From: hfreyther at sysmocom.de (Holger Freyther)
Date: Mon, 4 Sep 2017 22:02:43 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <20170903184139.m52dzicwso3vhr3d@nataraja>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja> <20170903000833.GB15743@my.box>
 <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>
 <20170903184139.m52dzicwso3vhr3d@nataraja>
Message-ID: <CF0C5348-4425-4F1E-AB6A-38387A2EA158@sysmocom.de>


> On 3. Sep 2017, at 20:41, Harald Welte <laforge at gnumonks.org> wrote:


Hi,


> Today the cgit jail quota again was exceeded and we saw 504 http errors
> when accessing http://git.osmocom.org/
> 
> The reason was indeed that the cache grew to fill the entire 5GB quota.
> 
> I checked what kind of files were occupying that much cache: Unfortunately
> more than 150 files each larger than 10MBytes as a result of cgit caching
> the .tar.gz snapshots it creates.
> 
> Unfortunately the cgit cache can only be restricted in number of files, not
> in terms of total size or "don't cache files larger than X".
> 
> As a workaround I disabled snapshot generation for now.  I presume there
> was some crawler that generated snapshots for lots of commits.

we had enabled snapshots as some of "our" Osmocom developers wanted the
feature. And some people continue to clone the website (as if cloning a
git repository couldn't be done easier).

On my todays flight I came up with a solution but will only implement it
the next days (unless someone else is doing it).

* disable caching in cgit
* enable caching inside the cgit nginx for the majority of URLs. Luckily
with git the rendering of a specific commit will not change...
* have crawler specific robots.txt to disable the SEO ones..


what do you think?

	holger


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



From laforge at gnumonks.org  Mon Sep  4 20:13:18 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 4 Sep 2017 22:13:18 +0200
Subject: cgit.osmocom.org was down / ezjail disk quota managed by zfs
In-Reply-To: <CF0C5348-4425-4F1E-AB6A-38387A2EA158@sysmocom.de>
References: <20170902011433.GE2278@my.box>
 <20170902080324.akjpklf5wex7mgdd@nataraja>
 <20170903000833.GB15743@my.box>
 <8BE59BE4-CEE7-4479-BAD7-CA412E5B4E92@sysmocom.de>
 <20170903184139.m52dzicwso3vhr3d@nataraja>
 <CF0C5348-4425-4F1E-AB6A-38387A2EA158@sysmocom.de>
Message-ID: <20170904201318.4j2fqbaaflwle2c5@nataraja>

Hi Holger,

On Mon, Sep 04, 2017 at 10:02:43PM +0200, Holger Freyther wrote:

> we had enabled snapshots as some of "our" Osmocom developers wanted the
> feature. And some people continue to clone the website (as if cloning a
> git repository couldn't be done easier).

thanks for pointing this out.  I'll make a comment in the config file
about this.

> On my todays flight I came up with a solution but will only implement it
> the next days (unless someone else is doing it).
> 
> * disable caching in cgit
> * enable caching inside the cgit nginx for the majority of URLs. Luckily
> with git the rendering of a specific commit will not change...

it changes, there's a small grey timestamp at the bottom of each html
page (unless the page is raw).  I had to figure this out when finding
URLs that I could use to reliably invalidate the Docker cachen once a
given branch of a repo changes.  See e.g. line 20 of
http://git.osmocom.org/docker-playground/tree/osmo-ggsn-master/Dockerfile#n20

So yes, most users probably won't care if the timestam at the bottom of
the html pages is wrong.

Please make sure though that URLS referring to specific branch HEADS are
not cached though, such as http://git.osmocom.org/openggsn/patch/?h=laforge/osmo-ggsn
as those are used from the Dockerfiles to detect if the HEAD of the
given branch has changed or not.

> what do you think?

First: Thanks for looking into this!  I think I would still prefer a
patch to cgit.  Limiting either the size of individual cached objects,
or having a soft limit on total size of the cache should be generally
useful features for upstream, not just for us.  But yes, it doesn't look
like a trivial way given how they implement the cache.  Maybe the
maintainers have an idea about this?

But then, up to you!

-- 
- 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 dr.blobb at gmail.com  Mon Sep  4 21:37:21 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Mon, 4 Sep 2017 23:37:21 +0200
Subject: jenkins and osmo-ci
In-Reply-To: <20170904134740.GA28592@my.box>
References: <20170809132843.GB32321@my.box>
 <CALQ9Oh05q31e=wbc+PzuUgBE6NkyJHyBm6MF=zCN8_OL6Kc=Rw@mail.gmail.com>
 <20170904134740.GA28592@my.box>
Message-ID: <CALQ9Oh25PknKoDSoudssxuoWLU6sznLsob-vM4PvRBDFVKDUuQ@mail.gmail.com>

Hi Neels,

Patchset for openBSC's jenkins.sh build script has been uploaded [1].

But a small change [2] of osmo-build.sh is necessarily pending,
because https://git.osmocom.org is down atm. Furthermore, the
osmo-build.sh script should probably not depend on cgit's
availability. :)

After [2] has been submitted following steps are necessary to verify
[1] via gerrit:

 - trigger "update-osmo-ci-on-slaves"
 - add ARTIFACT_STORE environment variable to all slaves/nodes e.g. [3]
 - add following arguments to docker invocations of openBSC jobs [4]:

     -e JOB_NAME="$JOB_NAME"
     -e ARTIFACT_STORE="/ARTIFACT_STORE"
     -v "$ARTIFACT_STORE:/ARTIFACT_STORE"


Afterwards, re-triggering [1] should result in a '+1 Jenkins Builder'.

I have sufficient permission to apply above stated steps, except
+2'ing [2] and you may want to suggest the absolute path for
ARTIFACT_STORE variable?

Regards,
   Andr?

[1] https://gerrit.osmocom.org/#/c/3823/
[2] https://gerrit.osmocom.org/#/c/3822/
[3] https://jenkins.osmocom.org/jenkins/computer/OsmocomBuild1/configure
[4] https://jenkins.osmocom.org/jenkins/view/Jenkins-Gerrit/job/OpenBSC-gerrit/


From nhofmeyr at sysmocom.de  Tue Sep  5 09:43:06 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 5 Sep 2017 11:43:06 +0200
Subject: jenkins and osmo-ci
In-Reply-To: <CALQ9Oh25PknKoDSoudssxuoWLU6sznLsob-vM4PvRBDFVKDUuQ@mail.gmail.com>
References: <20170809132843.GB32321@my.box>
 <CALQ9Oh05q31e=wbc+PzuUgBE6NkyJHyBm6MF=zCN8_OL6Kc=Rw@mail.gmail.com>
 <20170904134740.GA28592@my.box>
 <CALQ9Oh25PknKoDSoudssxuoWLU6sznLsob-vM4PvRBDFVKDUuQ@mail.gmail.com>
Message-ID: <20170905094306.GA2576@ass40.sysmocom.de>

Thanks, applied the OpenBSC-gerrit build config, and it started to build
now as https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2439/

It now reads:


chmod -R +w *
rm -rf *
git checkout .
#./contrib/jenkins.sh

ARTIFACT_STORE="$HOME/jenkins_build_artifact_store"
mkdir -p "$ARTIFACT_STORE"

docker run --rm=true \
  -e HOME=/build \
  -e ARTIFACT_STORE=/artifact_store \
  -e JOB_NAME="$JOB_NAME" \
  -e MAKE=make \
  -e PARALLEL_MAKE="$PARALLEL_MAKE" \
  -e IU="$IU" \
  -e SMPP="$SMPP" \
  -e MGCP="$MGCP" \
  -e PATH="$PATH:/build_bin" \
  -e OSMOPY_DEBUG_TCP_SOCKETS="1" \
  -w /build -i -u build \
  -v "$PWD:/build" \
  -v "$HOME/bin:/build_bin" \
  -v "$ARTIFACT_STORE:/artifact_store" \
  osmocom:amd64 /build/contrib/jenkins.sh


Notably, we are in the middle of moving to new repositories, away from
openbsc.git: osmo-msc.git, osmo-bsc.git, osmo-mgw.git, osmo-sgsn.git,
and when openbsc works with the artifact store these could follow.

~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/20170905/b6c2b503/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Sep  5 15:42:18 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 5 Sep 2017 17:42:18 +0200
Subject: jenkins slave setup and artifact re-use
Message-ID: <20170905154218.GA14245@ass40.sysmocom.de>

Hi Blobb,

I'd like to probe your opinion on a discussion we had today about our
jenkins. So far our setup was manual, and we would like to (somewhat)
automate the process of providing build dependencies on slaves.

One solution that was discussed longer than others would be to use docker.
Each of our repositories that need a build would have their own docker
file, containing the complete setup of dependencies. The idea is that
anyone can easily setup an identical build on any new jenkins build slave
or even at home; no complex config of the jenkins build slave is needed.

The point being, if we adopt docker in such a way, it would be logical to
make use of the docker cache to save unnecessary rebuilds. It is a generic
solution instead our artifact store.

I feel a bit bad for accepting your contributions, doing review and
keeping you busy, just to then talk about docker to solve the problem
instead; I appreciate your presence and would like to keep you involved.

Interestingly enough, we are experimenting with the artifact store on that
one build job that has already been using docker for quite some time...
(It was for the separate network space, not really for artifacts.)

In any case, I would like to include you in the discussion, and maybe you
would also like to be involved in maturing the idea? Until now it is still
wild and no-one has taken actual steps.

An example to follow would be laforge's recently added
https://git.osmocom.org/docker-playground/tree/

One interesting bit is that it has a method to check whether a given git
branch has changed, and rebuilds the docker image only if it has:
https://git.osmocom.org/docker-playground/tree/osmo-ggsn-master/Dockerfile#n20

  ADD http://git.osmocom.org/openggsn/patch/?h=laforge/osmo-ggsn /tmp/commit

This line fetches the given URL (in this case the latest patch on that
branch) and considers the docker image as unchanged if that URL shows the
same as last time. As soon as a new patch shows, things are rebuilt.

In this sense we could have docker images cascading on top of each other,
adding individual dependencies and reusing identical states auto-detected
by docker. All build steps would be in the Dockerfile.

For builds that aren't used by other builds (like the "final" programs,
osmo-msc, osmo-sgsn, osmo-bsc,...) we don't need to store the result, so
don't need to include the program's build in the Dockerfile: on a docker
image with all dependencies, run the final build step by invoking 'docker
run', like we currently do for the OpenBSC-gerrit job, and then just
discard the changes.

Remotely related: we have the osmo-gsm-tester that is running binaries
produced by jenkins to do automated tests on real GSM hardware.  Currently
we compile and tar the binaries, copy them over, extract, set
LD_LIBRARY_PATH and run: a bit tedious and problematic e.g. for
mismatching debian versions. This could be simplified by docker by
guaranteeing a fixed operating system around the binary, actually using
hub.docker.com (or maybe one day a private docker hub) instead of copying
over binary tars manually, sharing across any number of build slaves, and
with the added bonus of having the resulting binaries run in a separate
network space.

As I said, on the one hand I appreciate our work on the artifact store, on
the other hand the docker way undeniably makes for a good overall solution
to simplify things in general, with artifact re-use coming "for free"...

One advantage of the artifact store though is that the artifacts we manage
are not entire debian installations but just a few libs and executables in
a tiny tar.

What is your opinion?

~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/20170905/c6e37562/attachment.bin>

From laforge at gnumonks.org  Tue Sep  5 20:55:11 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 5 Sep 2017 22:55:11 +0200
Subject: RFC: Getting rid of FreeBSD build testing
Message-ID: <20170905205511.s7kpe4354zqgnksx@nataraja>

Dear all,

Holger and I (plus later the sysmocom team) had a discussion about whether
we should continue to keep the FreeBSD build testing.

Right now, jenkins is set up in a way to test build of a patch on Linux
(currently Debian 8) and FreeBSD (currently 10.3).  Only if it builds
and passes "make check", the patch gets the magical "+V" so it can be
merged.

While in general it's of course good practise to write portable code and
to test building on multiple operating systems, this adds quite a bit of
extra effort:
* patches every so often don't build on FreeBSD due to include header
  differences or the like, requiring extra iterations of a patch
* the build takes longer time as the build matrix is multiplied by two
  operating systems
* we cannot easily/safely migrate the way we buld to docker, as docker
  on FreeBSD is experimental

Particularly during my recent OpenGGSN developments (IPv6) support, this
was a big PITA and I'm sure I spent more time in debugging FreeBSD build
issues than actually writing the code in the first place.

Given that we arr not aware of anyone using the Osmocom stack on
FreeBSD, the suggestion is thus to focus our available time on actual GSM
related features rather than fixing up portability issues.

So unless we receive significant complains as a response to this e-mail,
we will disable the automatic build testing for patches on FreeBSD.
This doesn't mean we will drop related code from our projects.  We still
appreciate build and other fixes for other platforms, but those would
have to come as contributions from users on those platforms, rather than
something that's actively maintained and tested by Osmocom upstream.

If we want to extend build testing, I think it's more useful to have e.g.
ARM/Linux builds, or clang builds on Linux than the FreeBSD builds.

Let me know what you think.

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


From nhofmeyr at sysmocom.de  Tue Sep  5 21:42:36 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 5 Sep 2017 23:42:36 +0200
Subject: RFC: Getting rid of FreeBSD build testing
In-Reply-To: <20170905205511.s7kpe4354zqgnksx@nataraja>
References: <20170905205511.s7kpe4354zqgnksx@nataraja>
Message-ID: <20170905214236.GA17120@my.box>

Me personally, I once spent a few minutes extra on a FreeBSD build, a long time
ago.

On the other hand, most of the time my patches aren't tested on FreeBSD:
particularly openbsc.git as well as the new repositories haven't been tested
(for gerrit +V) on FreeBSD for a long time.

So FreeBSD has no significance for my daily work at all and I probably wouldn't
notice that it is gone.

Given involvement by some friends of mine I'd actually be more interested in
OpenBSD than FreeBSD ... but that's beside the point :)

~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/20170905/e0d2f69c/attachment.bin>

From laforge at gnumonks.org  Tue Sep  5 21:54:17 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 5 Sep 2017 23:54:17 +0200
Subject: RFC: Getting rid of FreeBSD build testing
In-Reply-To: <20170905214236.GA17120@my.box>
References: <20170905205511.s7kpe4354zqgnksx@nataraja>
 <20170905214236.GA17120@my.box>
Message-ID: <20170905215417.sgh67hwtafdvupj3@nataraja>

Hi Neels,

On Tue, Sep 05, 2017 at 11:42:36PM +0200, Neels Hofmeyr wrote:
> Me personally, I once spent a few minutes extra on a FreeBSD build, a long time
> ago.

lucky you.

> On the other hand, most of the time my patches aren't tested on FreeBSD:
> particularly openbsc.git as well as the new repositories haven't been tested
> (for gerrit +V) on FreeBSD for a long time.

Ah, ok, I missed that.

> Given involvement by some friends of mine I'd actually be more interested in
> OpenBSD than FreeBSD ... but that's beside the point :)

Well, as indicated we'd be more than happy to merge related patches, but
I just have doubts whether it's efficient use of our time to actively (build)
test the code on other platforms.

Also, if somebody wants to maintain this, we could keep a separate e.g. nightly
jenkins job around and then generate build failure notifications to whoever in
the community who wants to maintain the (sup)port for other platforms.

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 dr.blobb at gmail.com  Wed Sep  6 12:05:16 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Wed, 6 Sep 2017 14:05:16 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170905154218.GA14245@ass40.sysmocom.de>
References: <20170905154218.GA14245@ass40.sysmocom.de>
Message-ID: <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>

Hi Neels,

>> In any case, I would like to include you in the discussion,
>> and maybe you would also like to be involved in maturing the idea?

Thanks and sure, I already excitingly read mails with similar topics
like lxc and Jenkins YAML jobs. The latter will be commented soon.

>> This line fetches the given URL (in this case the latest patch on that
>> branch) and considers the docker image as unchanged if that URL shows the
>> same as last time. As soon as a new patch shows, things are rebuilt.

Great idea! So, the hourly/nightly jobs would "docker build..."
instead of "docker run..."?

Will there be one Dockerfile per each branch or is planned to use
docker's "ARG  and "--build-arg" to pass branch while building?

Furthermore, the nightly package of libosmocore-dev confuses me,
especially when thinking about gerrit jobs. How often are these
packages updated?

>> In this sense we could have docker images cascading on top of each other,
>> adding individual dependencies and reusing identical states auto-detected
>> by docker. All build steps would be in the Dockerfile.

Afaiu images will be rebuild if a new patch is introduced. But who is
invoking the rebuild when the parent or libosmocore-dev in the example
have changed?

Sharing same layer for "RUN apt-get install ..." command as shown in
osmo-nitb-master and osmo-bts-master Dockerfile could be promising.
But only if above mentioned rebuilding mechanism is smart enough to
build only one image first so following will reuse its layer.



In general I like the "move" towards docker compared to lxc, which
does not provide something similar to a Dockerfile.

On the one hand the described (free) benefits sounds really promising.
On the other hand I am skeptic about the whole life cycle, which imo
needs some external management as described to keep everything up to
date. Additionally, every "docker run ..." command would need a
"docker pull ..." before to ensure latest image from repository.

I will definitely setup some build jobs on my Jenkins with those
Docker images to get a better understanding.


P.S.: >> I feel a bit bad for accepting your contributions, doing
review and keeping you busy

No worries at all! :)


From dr.blobb at gmail.com  Wed Sep  6 12:40:26 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Wed, 6 Sep 2017 14:40:26 +0200
Subject: jenkins build slaves: Rationale for some builds in docker vs.
 some not?
In-Reply-To: <20170830115321.GA2050@my.box>
References: <20170825111515.l3lyp76cqv3cfqlh@nataraja>
 <4195E9A7-50AC-4866-AEE6-4013B0542E80@freyther.de>
 <20170827142852.GB2805@my.box>
 <236AF04A-5604-486A-ABE8-7020CA05046D@freyther.de>
 <20170830115321.GA2050@my.box>
Message-ID: <CALQ9Oh0QeAvdGXXtHJFUYA3N=QMvNNSUDvR+U=vuH5_=8ntMiQ@mail.gmail.com>

+1 for moving towards describing jobs instead of clicking them!

I haven't used yaml DSL, only JobDSL and Pipeline so far. I will try
to migrate some jobs (nightly, gerrit) to yaml DSL to see if all
needed configurations are available and let you know. Or did someone
already check this?

2017-08-30 13:53 GMT+02:00 Neels Hofmeyr <nhofmeyr at sysmocom.de>:
> 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



-- 
Gru?
Blobb


From laforge at gnumonks.org  Wed Sep  6 13:05:27 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Sep 2017 15:05:27 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
Message-ID: <20170906130527.vunhiqrakvkfdddb@nataraja>

Hi Andre,

On Wed, Sep 06, 2017 at 02:05:16PM +0200, Andr? Boddenberg wrote:
> 
> >> This line fetches the given URL (in this case the latest patch on that
> >> branch) and considers the docker image as unchanged if that URL shows the
> >> same as last time. As soon as a new patch shows, things are rebuilt.
> 
> Great idea! So, the hourly/nightly jobs would "docker build..."
> instead of "docker run..."?

no, every 'docker run' job would be preceeded with a 'docker build', which
would either rebuild the image if needed (based on the "ADD" patch URL)
or simply use the most recent image from the cache.

There would be one image/Dockerfile that builds libosmo* in it at
'docker build' time, and which then is used with 'docker run' to build
the specific application for which you're doing build testing, e.g.
osmo-bsc or osmo-hlr.

The build test at 'docker run' time would then happen completely inside
the docker tmpfs overlay and is expected to run super quick,
particularly given that build-2 has 64GB of RAM.  If we want to keep
some artefacts, then those would have to be copied (e.g. during "make
install" to a bind-mount/volume).

> Will there be one Dockerfile per each branch or is planned to use
> docker's "ARG  and "--build-arg" to pass branch while building?

In the basic form I would see only one dockerfile+image for libosmo* in
master branch that can be used for all osmo-* application build testing.

The given project that you want to build-test would either
a) not be part of that dockerfile/image but simply cloned at 'docker
   run' time.  Disadvantage: Must be cloned from scratch.

b) a 'git clone' base version of the (or all?) application-under-test
   could be part of the Dockerfile/image, so that at 'docker run' time
   we simply do a git pull + checkout -f -B of the specific branch we
   want to build.  Advantage: no need to clone from scratch at every
   build, only the delta between 'when image was built last' and the
   branch/patch-under-test needs to be fetched from the git server

for 'b' all git repos could be cloned into the base Dockerfile/image,
or we could have one program-specific Dockerfile/image.  In the context
of simplicity, I would try to reduce the different number of
Dockerfiles/images, and simply have "all-in-one".  The age of those
"program under test" clones doesn't matter (so no "ADD http://cgit..."),
as opposed to the age of the build dependencies, which must be ensured.

> Furthermore, the nightly package of libosmocore-dev confuses me,
> especially when thinking about gerrit jobs. How often are these
> packages updated?

The current Dockerfiles in docker-playground.git are built for executing
test software.  They re not meant for build testing, please don't
confuse those two.

> Afaiu images will be rebuild if a new patch is introduced. But who is
> invoking the rebuild when the parent or libosmocore-dev in the example
> have changed?

image[s] will only need to be rebuilt when a patch to the build
dependencies is introduced to the master of such a dependency.  They
will not be upated by a patch to the project/repo/app-under-test, as
that one is not part of the image.

The rebuild of the 'libosmo*' image is triggered by 'docker build' at
the beginning of e.g. osmo-bsc-gerrit job.

> Sharing same layer for "RUN apt-get install ..." command as shown in
> osmo-nitb-master and osmo-bts-master Dockerfile could be promising.

I think that's not really relevant to build-testing.

> In general I like the "move" towards docker compared to lxc, which
> does not provide something similar to a Dockerfile.

Well, it provides templates.  Similar, but of course different (and no
layer cachce, ...)

> On the other hand I am skeptic about the whole life cycle, which imo
> needs some external management as described to keep everything up to
> date. 

no, fully automatic.

> Additionally, every "docker run ..." command would need a
> "docker pull ..." before to ensure latest image from repository.

If you do a 'docker build' ahead of every 'docker run', I don't see that
need.

> I will definitely setup some build jobs on my Jenkins with those
> Docker images to get a better understanding.

Please don't use the Dockerfiles in docker-playground.git.  As
indicated, they are built for a completely different purpose and hence
work differently.

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


From laforge at gnumonks.org  Wed Sep  6 15:22:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Sep 2017 17:22:04 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170906130527.vunhiqrakvkfdddb@nataraja>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
Message-ID: <20170906152204.22d64g4p5xwjn3tk@nataraja>

Hi Andre,

On Wed, Sep 06, 2017 at 03:05:27PM +0200, Harald Welte wrote:
> In the basic form I would see only one dockerfile+image for libosmo* in
> master branch that can be used for all osmo-* application build testing.

I've prototyped this at http://git.osmocom.org/docker-playground/tree/osmo-gerrit-libosmo/Dockerfile

If you're trying this, make sure you're running it using 'make run' or
manually including the "--tmpfs /tmpfs:exec" arguments.

The VTY tests of course take ages, but the actual build of openbsc.git
is pretty fast and executed on /tmpfs.

if the jenkins job for openbsc-gerrit would then do
* docker build ...
* docker run ...

Then the latest openbsc.git would be built and automatically all upstream
dependencies are updated from latest master - but only if the latest
master of those dependencies has changed (unlike current osmo-deps.sh).

This is of course all just a prototype, and proper scripts/integration
is needed.

-- 
- 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 dr.blobb at gmail.com  Wed Sep  6 18:45:02 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Wed, 6 Sep 2017 20:45:02 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170906152204.22d64g4p5xwjn3tk@nataraja>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
Message-ID: <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>

Hi Harald,


thanks for the clarification! As said, I was wondering about the
Dockerfiles, especially about the EXPOSE and CMD command.

The osmo-gerrit-libosmo Docker file is great. A first hands on showed
that a openbsc verification build finishes in 5+ minutes and a
osmo-msc build in breath taking 18s!!!

All my concerns about the full automation of using latest dependencies
AND latest base image are gone.


>> This is of course all just a prototype, and proper scripts/integration
>> is needed.

Would it be helpful to set up gerrit verification jobs of mentioned
"applications" in the Dockerfile.? I am currently trying to set up a
gerrit verification job with YAML DSL (Jenkins Job Builder) and could
combine both spikes.


Regards,
   Andr?


From laforge at gnumonks.org  Wed Sep  6 19:37:20 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Sep 2017 21:37:20 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
 <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
Message-ID: <20170906193720.bqgvpleubbxqr5sh@nataraja>

Hi Andre,

On Wed, Sep 06, 2017 at 08:45:02PM +0200, Andr? Boddenberg wrote:
> The osmo-gerrit-libosmo Docker file is great. A first hands on showed
> that a openbsc verification build finishes in 5+ minutes and a
> osmo-msc build in breath taking 18s!!!

This is good news. Happy you like it.

> All my concerns about the full automation of using latest dependencies
> AND latest base image are gone.

Great.

After that much praise, there's also a downside:

* we currently install libosmo* to /usr/local using 'sudo'.  There's actually
  no real reason for this, one could install into some other
  user-writable PREFIX and use that at compile ('docker run') time.
  Would be great to see some patches cleaning this up

* we always have all dependencies installed, i.e. we're no longer trying
  to do builds with certain libraries not present.  Let's say we wnat to
  do an osmo-msc --disable-smpp build: libsmpp34 will still be present,
  and we *could* introduce unnoticed bugs that would only show up once
  libsmpp34 is actually not present.   One could either not worry too
  much about it, or one could do some more PKG_CONFIG_PATH hackery with
  different PREFIX for the different libraries so that each library is
  in a different PREFIX and the librray is not found unless we
  explicitly pass the related paths to ./configure.

  I'm not sure if it's worth investing too mcuh time into this, given
  that lots of conditionals go away in the split-nitb scenario:
  osmo-bsc always implicitly requires "--enable-osmo-bsc" and osmo-sgsn
  always implicitly requires libgtp.  However, there's still the SMPP
  example.

  What do others say? Is this important to test?  If so, do we have
  volunteers to look into writing scripts for this?

* In terms of artefacts, we should figure out which ones we want to
  keep.  For sure any kind of log files like config.log should be copied
  from the tmpfs to the workspace before we kill the container.  They
  might contain useful information.  One *might* also want to do a "make
  install" to the workspace?  So to me config.log is a must, everything
  else is "optional, later, if somebody needs it".  But then, Pau had
  some other opionion, AFAIR.

> >> This is of course all just a prototype, and proper scripts/integration
> >> is needed.
> 
> Would it be helpful to set up gerrit verification jobs of mentioned
> "applications" in the Dockerfile.? I am currently trying to set up a
> gerrit verification job with YAML DSL (Jenkins Job Builder) and could
> combine both spikes.

That would be much appreciated.  I think the biggest missing part is
figuring out some helper scripts to easily 'run' that Docker container
with the related arguments.  I guess a given jenkins job then should
only call that helper script and pass the "configure" arguments and some
environment variables like our PARALLEL_MAKE?  I wouldn't want to
clutter the jenkins job definitions with repetetive long hand-crafted
'docker run' commands.

The next question is then where to store all of this.  Given that this
helper script as well as the Dockerfile is quite generic, it should
probably go into osmo-ci.  But then, the Dockerfile depens on stuff from
docker-playground.  We could merge the two or keep the Dockerfile in
docker-playground and just put the helper script in osmo-ci?  Actually,
the part of the script that's running inside the container could be
included in the image at 'docker build' time.  Only the 'docker run'
wrapper that's used to start a container is external.

In any case, from my point of view a given jenkins gerrit job should do:
* git fetch && git checkout -f -B master origin/master on * osmo-ci/docker-playground
  to make sure we catch any updates to those
* 'docker build' of the respective docker image
* 'docker run' by means of some helper script, using the respective
  arguments / build matrix options as required by the given job/project,
  as well as the exact git commit we want to test-build (instead of
  master)

The current image should work for
{openbsc,osmo-{bsc,bts,pcu,mgw,sgsn,ggsn,trx,hlr},openggsn}-gerrit jobs

For the library projects {libasn1c,libsmpp34,libosmo{core,-abis,-netif,-sccp}}
and others which have some downstream build dependencies, we could also
use the same docker base image.  However, some additional concerns:
* when building e.g. libosmocore on a container that already has a
  system-wide installation of libosmocore, we could accidentially use
  include files from the system (/usr/local/include), rather than those
  of the current branch/commit that we're trying to build.  One more
  reason not to install into /usr/local but into specific prefixes (see
  above) and then tell each given build which of the prefixes to use or
  not, depending on its build dependencies
* we might want to test to build (some of?) the downstream dependencies,
  as e.g. a commit in libosmocore might break osmo-bts.

Any help / work in the above areas (and anything I might have missed) is
much appreciated.  I won't have any more time to work on this, too many
other topics going on :/

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


From nhofmeyr at sysmocom.de  Thu Sep  7 04:53:28 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 7 Sep 2017 06:53:28 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170906193720.bqgvpleubbxqr5sh@nataraja>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
 <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
 <20170906193720.bqgvpleubbxqr5sh@nataraja>
Message-ID: <20170907045328.GA16047@my.box>

The one thing I would have done differently: 

Why not have a series of Dockerfiles for each git, building onto the Dockerfile
of its "next" dependency?

By having all gits in one joint image we "smudge" the build environment, or
need to worry about cleaning things up first.

You said you would prefer having not so many images around, but what is the
reason? I thought the images were incremental, and if one references the
previous, there is only a small difference taking up space for it?

I'm thinking of a cascade like this:

 debian
  \
   libosmocore
   |
   libosmo-abis
   |
   +---------------- osmo-hlr
   |
   libosmo-netif
   |
   libosmo-sccp
   |
   osmo-iuh
   |
   +---------------- osmo-ggsn
   |                 |
   |                 osmo-sgsn
   |
   osmo-mgw
   |
   libsmpp34
   |
   +---------------- osmo-bsc
   +---------------- osmo-msc

It's a compromise of least dependencies and avoiding dupes, resulting in 13
different stages.

The libosmocore job would update the libosmocore image, the libosmo-abis job
builds on it to produce the libosmo-abis image, and so forth. The jenkins jobs
would naturally re-use the other jobs' results and be clean every time.

The downside is to have to run ~8 different images for a core network (e.g. on
the osmo-gsm-tester). But is docker managing it such that it doesn't take up 8
x the space and RAM, just one debian + 8 little increments?

On the osmo-gsm-tester we can then freely combine various versions of the
different core network components by simply running a different image per
binary. Would be great to not build separate tester images anymore.

Anyway, that was my first intuition. Maybe one joint image is more practical
after all, but harder for me to imagine ATM.

~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/20170907/1bc32867/attachment.bin>

From dr.blobb at gmail.com  Thu Sep  7 13:34:48 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Thu, 7 Sep 2017 15:34:48 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170907045328.GA16047@my.box>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
 <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
 <20170906193720.bqgvpleubbxqr5sh@nataraja> <20170907045328.GA16047@my.box>
Message-ID: <CALQ9Oh2Ju3iggBgZSoZKdzH+GGbB=9FvNoC-ykj9oKYk-am1jg@mail.gmail.com>

Hi Neels,

>> The libosmocore job would update the libosmocore image, the libosmo-abis job
>> builds on it to produce the libosmo-abis image, and so forth. The jenkins jobs
>> would naturally re-use the other jobs' results and be clean every time.

Of course this will work, but afaics it won't suite for gerrit
verifications. Because docker always takes the latest available base
image. So if libosmocore image is currently rebuild and didn't finish
yet, a libosmo-abis docker build, which uses libosmocore as base image
wouldn't wait until the "new" libosmocore image is built, it would
simply use the "old" one. That's why I really like the "one container"
solution for gerrit verifications, which checks whether all
dependencies are up to date by a "docker build" invocation.

>> Would be great to not build separate tester images anymore.

My knowledge about the gsm-tester is quite limited to its manual and I
agree with the general idea of reusing things, but it might be better
to have Docker images for precise purposes?


My spike with Harald's gerrit-verification image [1] and
jenkins-job-builder [2] will probably finish next week (mo/tu).

BR,
 Andr?

[1] https://git.osmocom.org/docker-playground/tree/osmo-gerrit-libosmo/Dockerfile
[2] https://pypi.python.org/pypi/jenkins-job-builder/


From laforge at gnumonks.org  Thu Sep  7 14:09:26 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 7 Sep 2017 16:09:26 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170907045328.GA16047@my.box>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
 <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
 <20170906193720.bqgvpleubbxqr5sh@nataraja>
 <20170907045328.GA16047@my.box>
Message-ID: <20170907140926.tou2inpp4w6lyw2j@nataraja>

Hi Neels,

On Thu, Sep 07, 2017 at 06:53:28AM +0200, Neels Hofmeyr wrote:
> Why not have a series of Dockerfiles for each git, building onto the Dockerfile
> of its "next" dependency?

To avoid complexity and having too maintain too many Dockerfiles, related images, etc.

I think one of the beauties of the proposal is that we reduce the amount of
things that need explicit maintenance.

> You said you would prefer having not so many images around, but what is the
> reason? I thought the images were incremental, and if one references the
> previous, there is only a small difference taking up space for it?

Sure, space-wise it doesn't matter.  I'm more thinking of having to
maintain the Dockerfiles

> I'm thinking of a cascade like this:
> 
>  debian
>   \
>    libosmocore
>    |
>    libosmo-abis
>    |
>    +---------------- osmo-hlr

this would mean you would have to
* docker build the libosmocore image to check/update to current master
* docker build the libosmo-abis image
* docker run the build for osmo-hlr

If this splits up to even more images, you will end up having something
like 8 'docker build' followed by one 'docker run' in each gerrit job.
I'm not sure how much of the performance gain we will loose that way.

> It's a compromise of least dependencies and avoiding dupes, resulting in 13
> different stages.

complexity, and manually having to re-trigger builds in the right
inverse dependency order in every jenkins job.

> The libosmocore job would update the libosmocore image, the libosmo-abis job
> builds on it to produce the libosmo-abis image, and so forth. The jenkins jobs
> would naturally re-use the other jobs' results and be clean every time.

> The downside is to have to run ~8 different images for a core network (e.g. on
> the osmo-gsm-tester). But is docker managing it such that it doesn't take up 8
> x the space and RAM, just one debian + 8 little increments?

I cannot comment on memory usage of running lots of images in parallel.
As indicated, my proposal was related to gerrit builds, not related to
images that can be used to execute the individual osmo-* components.

> On the osmo-gsm-tester we can then freely combine various versions of the
> different core network components by simply running a different image per
> binary. Would be great to not build separate tester images anymore.

The same applies for the TTCN3 tests, for which I build using the
current docker-playground.  There, each element has a separate image.

Sure, we should aim for overlap where possible and have common ancestors
between the Dockerfiles used for gerrit build testing and those for
actual per-network-element-containers. 

But in the end, I think those are fundamentally different.  In terms of
how often you build them, and in terms of whether you actually want to
keep everything you built vs. building in tmpfs and discarding
everything

-- 
- 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 Sep  7 17:02:21 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 7 Sep 2017 19:02:21 +0200
Subject: OsmoBTS after NITB split
Message-ID: <c686b9a7-3873-3967-7415-e7f4dba530fc@sysmocom.de>

Hi.

The OsmoBTS build depends (unfortunately) on OpenBSC because it uses
gsm_data_shared.h header. ATM this file is available in osmo-bsc and osmo-msc (maybe
other split repos as well). Which is the "canonical" one from OsmoBTS point of view?

Also, when would be the right time to move OsmoBTS' jenkins job to use one of the
split repos instead of old OpenBSC?

-- 
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 phippsr at cs.washington.edu  Thu Sep  7 18:15:49 2017
From: phippsr at cs.washington.edu (Rowan Phipps)
Date: Thu, 07 Sep 2017 18:15:49 +0000
Subject: OpenBSC USSD external application
In-Reply-To: <CABmJbFUEn-RjHbTHMcgBZdQ2hZZtn-+Oic8RC2+QRrC7R_jbzg@mail.gmail.com>
References: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>
 <CABmJbFUEn-RjHbTHMcgBZdQ2hZZtn-+Oic8RC2+QRrC7R_jbzg@mail.gmail.com>
Message-ID: <CA+YA_XQuV3Oo4tkSO+hX4K5jOj_hpfPEze8AW06TfuA13U+D5w@mail.gmail.com>

Do you know which version of libosmocore that branch worked with?  I have
tried it with both the master branch and the fairwaves/master-rebase branch
and neither one compiled.  I also tried rebasing the
fairwaves/master-rebase onto master again.  This at least builds but it
looks like osmo-nitb is sending a different version of SUP than what
libosmocore is expecting and so it can't decode it.  The function in
libosmocore that seems to do the decoding is osmo_gsup_decode in gsup.c

I have seen references to be SUP and GSUP in the code.  Are these two
different protocols or are they the same thing?  Also, are they specified
anywhere other than in the code?


On Sat, Sep 2, 2017 at 2:11 PM Alexander Chemeris <
alexander.chemeris at gmail.com> wrote:

> Hi Rowan,
>
> A more recent version of this work is a part of the
> fairwaves/master-rebase branch. It has implementation of exporting
> USSD (and any other SS for that matter) over a SUP socket and an
> external utility to decode/encode them and convert to/from SIP+XML
> similar to defined in the IMS standard.
>
> We're currently using this code to implement external USSD services
> like a balance check from a billing system and also to forward SS and
> USSD to MAP/Sigtran. So I think the code should work well for you.
>
> If you find this code useful, we would greatly appreciate any help in
> merging this code into master. We intend to eventually merge this into
> master, but it requires some cleanup before it could be submitted for
> a review and given it's not a simple small change we've never had
> enough time to do that so far :(
>
> On Wed, Aug 30, 2017 at 10:59 PM, Rowan Phipps
> <phippsr at cs.washington.edu> wrote:
> > 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
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CTO/Founder, Fairwaves, Inc.
> https://fairwaves.co
>
-- 
Thanks!
    - Rowan Phipps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170907/ab63c21b/attachment.htm>

From laforge at gnumonks.org  Thu Sep  7 19:04:50 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 7 Sep 2017 21:04:50 +0200
Subject: OsmoBTS after NITB split
In-Reply-To: <c686b9a7-3873-3967-7415-e7f4dba530fc@sysmocom.de>
References: <c686b9a7-3873-3967-7415-e7f4dba530fc@sysmocom.de>
Message-ID: <20170907190450.eyexvw6x362ttf3r@nataraja>

On Thu, Sep 07, 2017 at 07:02:21PM +0200, Max wrote:
> Hi.
> 
> The OsmoBTS build depends (unfortunately) on OpenBSC because it uses
> gsm_data_shared.h header. 

I think we should give up on the shared header and just have two copies, each with what's
needed on either side.  It looked like a good idea at the time when we started out
creating OsmoBTS under a lot of time pressure after writing OpenBSC/OsmoNITB.

I think we should clean it up as follows:
* generic definitionns about coding schemes, value_strings for pchan_types etc
  can go straight into libosmogsm
* the core data model (struct gsm_{bts,trx,ts}, gsm_lchan, ...) should go into
  a new libosmo-bss which is part of libosmocore.git
* those data structures in libosmo-bss are reduced to only contain the common
  parts that are not bts/bsc specific, and a *priv or *role, which is then
  allocated and filled-in with program (bts/bsc) specific data/struct

But then, I guess we have more important work than to refactor something that has
worked for more than 5 years :/

btw: I don't think osmo-msc needs to use gsn_data_shared at all, at
least conceptually it shouldn't have any need to?

> Also, when would be the right time to move OsmoBTS' jenkins job to use one of the
> split repos instead of old OpenBSC?

I think it could be done at any time, osmo-bsc.git is ready.

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


From nhofmeyr at sysmocom.de  Thu Sep  7 20:05:54 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 7 Sep 2017 22:05:54 +0200
Subject: breaking VTY config compat -- was: catch-22 VTY error
In-Reply-To: <20170509104638.GB2411@ass40.sysmocom.de>
References: <20170508221512.GA2430@my.box>
 <20170509050627.iwlfjlhtsekzob7e@nataraja>
 <20170509104638.GB2411@ass40.sysmocom.de>
Message-ID: <20170907200554.GA7493@ass40.sysmocom.de>

On Tue, May 09, 2017 at 12:46:38PM +0200, Neels Hofmeyr wrote:
> On Tue, May 09, 2017 at 07:06:27AM +0200, Harald Welte wrote:
> > Hi Neels,
> > 
> > On Tue, May 09, 2017 at 12:15:12AM +0200, Neels Hofmeyr wrote:
> > > About 2: we tend to indent our VTY config files, but in fact the indentation
> > > has no effect whatsoever, it is just eye candy (very useful eye candy).
> > 
> > Maybe we should change that part, rather than renaming commands for no
> > good reason?  We could use the indent level to generate 'virtual node
> > exit' commands...

A patch for this exists on gerrit now and sees some interesting
discussion:
https://gerrit.osmocom.org/3880


Maybe we can move the discussion here for easier reading / writing:
(copying the comments so far from gerrit)

msuraev:
> I think it deserves wider discussion in ML because it have a chance to
> break pretty much every Osmocom config file out there.

I fully agree, and there already was some discussion on the ML, which lead
up to this patch: see thread before and after
https://lists.osmocom.org/pipermail/openbsc/2017-May/010652.html
("catch-22 VTY error")

I am touching this now because I think we're releasing a burst of people
needing to adjust their vty config files these days (with osmo-msc/bsc
separation and osmo-ggsn, the new SIGTRAN and whatnot), and it would make
sense to do this indenting change at the same time.

Actually I think it might be worth it to make this indenting strictness
optional, so that e.g. the old osmo-nitb can still request the old
implicit-go-to-parent way, while new binaries from a given version on can
switch to the new strict indenting.

Though we're writing a lot here now, I would welcome more discussion on
the ML...


hwelte:
> Thanks for looking into this.  I think it might be difficult to insist on
> one space idnent per level. It would be much mor user friendly if there
> was a notion of 'parent node depth', i.e. you can use any number of
> additional spaces to indent a new depth level, and as soon as you go back
> beyond that depthy level we go to the parent.  Not sure how comple that
> would be to implement?

Currently the VTY only remembers a single node.
It relies on the node commands to pick a child node, and on go_parent_cb()
to pick the right parent for each child.

i.e. there is no state about parent nodes at all.
To remember which depths each parent node was on, we would need to create
such state per parent node. So the effort is non-trivial.

But nevertheless, I like that, because we will hardly ever step in deeper
than say five child node levels and keeping the state is far from
performance / memory critical. Also it would obsolete the need for the
go_parent callbacks, and we could actually define the child->parent
relations merely from entering a child. (One step further could even
define the parent->child relations statically when defining VTY commands,
instead of writing code to enter another node, opening up the possibility
to validate that the parent/child structure is sound).

My main question is, how much of this code do we want to change? Is there
a consideration like with llist, that we don't want to deviate from
upstream too much?

> Also, if we now have a notion of the "depth", could this somehow be used
> to automatically generate the required spaces in front of a string when
> saving the file (config_write_...())?  So far we manually have to print
> those spaces which is a bit ugly (and doesn't permit a node to appear at
> different parent nodes / depths).

That's a bit harder, because for writing the config we simply vty_out().
There would need to be some wrapper function prepending indent, plus some
function indicating that we stepped in and out of a child node to modify
the prepended indent. We still have to take care that we indicate that
properly:

  network
   bts 0
    arfcn 123
   bts 1

From 'arfcn' up to bts 1, we still have to manually indicate that we
intended to step out of the bts 0 child node.

Also structures like this are valid:

  network
   bts 0
   bts 1

i.e. bts 0 would intend to enter a child node, but bts 1 follows right
away on the same level, i.e. steps out of it again. There isn't any way
that saves us from indicating those levels manually; we can only save
ourselves from varying spaces while in a specific node by accident. Not
sure if it's worth the trouble / easier to just indicate the depth by
manual spaces.

> (and doesn't permit a node to appear at different parent nodes /
> depths).

For <thing I don't remember> I once wrote a vty_write wrapper that
accepted the parent node and level of indent flexibly, so that two
different binaries could hook a library vty on arbitrary node depth
levels... pretty straightforward.

(end of quote)

~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/20170907/8d10f583/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Sep  7 20:12:12 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 7 Sep 2017 22:12:12 +0200
Subject: breaking VTY config compat -- was: catch-22 VTY error
In-Reply-To: <20170907200554.GA7493@ass40.sysmocom.de>
References: <20170508221512.GA2430@my.box>
 <20170509050627.iwlfjlhtsekzob7e@nataraja>
 <20170509104638.GB2411@ass40.sysmocom.de>
 <20170907200554.GA7493@ass40.sysmocom.de>
Message-ID: <20170907201212.GB7493@ass40.sysmocom.de>

On Thu, Sep 07, 2017 at 10:05:54PM +0200, Neels Hofmeyr wrote:
> I am touching this now because I think we're releasing a burst of people
> needing to adjust their vty config files these days

I like how this reads ambiguously :)
You get what I mean, right...

~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/20170907/96cdbb7a/attachment.bin>

From djks74 at gmail.com  Thu Sep  7 06:05:47 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Thu, 7 Sep 2017 13:05:47 +0700
Subject: Registering problem on osmo-bts
Message-ID: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>

Dear guys,
anyone can help me, Im using osmo-gsm-tester osmo-bts.cfg and openbsc.cfg
also/
BTS is up and auth policy accept-all is set and even I add subscriber IMSI,
but my phone still cannot register on the network.

my setup is LimeSDR and using the latest osmo-bts and openbsc with OpenUSRP.

do you think its a hardware issue?

please help! Thanks

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

From ivan.kluchnikov at fairwaves.co  Fri Sep  8 09:16:35 2017
From: ivan.kluchnikov at fairwaves.co (Ivan Kluchnikov)
Date: Fri, 8 Sep 2017 12:16:35 +0300
Subject: OpenBSC USSD external application
In-Reply-To: <CA+YA_XQuV3Oo4tkSO+hX4K5jOj_hpfPEze8AW06TfuA13U+D5w@mail.gmail.com>
References: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>
 <CABmJbFUEn-RjHbTHMcgBZdQ2hZZtn-+Oic8RC2+QRrC7R_jbzg@mail.gmail.com>
 <CA+YA_XQuV3Oo4tkSO+hX4K5jOj_hpfPEze8AW06TfuA13U+D5w@mail.gmail.com>
Message-ID: <CA+QHiD9_Bv72JyTpB40UD5z=dZGwFud5SsPdkHS7iaV24+FiJQ@mail.gmail.com>

Hello Rowan,

You should use:
for libosmocore: fairwaves/master-rebase branch
for openbsc: fairwaves/master-rebase branch and use
./configure --enable-ussd-proxy

2017-09-07 21:15 GMT+03:00 Rowan Phipps <phippsr at cs.washington.edu>:

> Do you know which version of libosmocore that branch worked with?  I have
> tried it with both the master branch and the fairwaves/master-rebase branch
> and neither one compiled.  I also tried rebasing the
> fairwaves/master-rebase onto master again.  This at least builds but it
> looks like osmo-nitb is sending a different version of SUP than what
> libosmocore is expecting and so it can't decode it.  The function in
> libosmocore that seems to do the decoding is osmo_gsup_decode in gsup.c
>
> I have seen references to be SUP and GSUP in the code.  Are these two
> different protocols or are they the same thing?  Also, are they specified
> anywhere other than in the code?
>
>
> On Sat, Sep 2, 2017 at 2:11 PM Alexander Chemeris <
> alexander.chemeris at gmail.com> wrote:
>
>> Hi Rowan,
>>
>> A more recent version of this work is a part of the
>> fairwaves/master-rebase branch. It has implementation of exporting
>> USSD (and any other SS for that matter) over a SUP socket and an
>> external utility to decode/encode them and convert to/from SIP+XML
>> similar to defined in the IMS standard.
>>
>> We're currently using this code to implement external USSD services
>> like a balance check from a billing system and also to forward SS and
>> USSD to MAP/Sigtran. So I think the code should work well for you.
>>
>> If you find this code useful, we would greatly appreciate any help in
>> merging this code into master. We intend to eventually merge this into
>> master, but it requires some cleanup before it could be submitted for
>> a review and given it's not a simple small change we've never had
>> enough time to do that so far :(
>>
>> On Wed, Aug 30, 2017 at 10:59 PM, Rowan Phipps
>> <phippsr at cs.washington.edu> wrote:
>> > 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
>>
>>
>>
>> --
>> Regards,
>> Alexander Chemeris.
>> CTO/Founder, Fairwaves, Inc.
>> https://fairwaves.co
>>
> --
> Thanks!
>     - Rowan Phipps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170908/e0f97dd5/attachment.htm>

From laforge at gnumonks.org  Fri Sep  8 09:22:36 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 8 Sep 2017 11:22:36 +0200
Subject: Registering problem on osmo-bts
In-Reply-To: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>
References: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>
Message-ID: <20170908092236.5sl5fc6jp3sleqbw@nataraja>

Hi Sandi,

On Thu, Sep 07, 2017 at 01:05:47PM +0700, Sandi Suhendro wrote:
> anyone can help me, Im using osmo-gsm-tester osmo-bts.cfg and openbsc.cfg

Where are your detailed log files and the related PCAP files of abis and Um/GSMTAP?

Please see https://media.ccc.de/v/osmocon17-4008-reporting_and_investigating_issues_in_osmocom for a tutorial
on how to best report issues.

We want to help, but we need reliable information to determine what's happening.

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


From djks74 at gmail.com  Fri Sep  8 09:37:49 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Fri, 8 Sep 2017 16:37:49 +0700
Subject: Registering problem on osmo-bts
In-Reply-To: <20170908092236.5sl5fc6jp3sleqbw@nataraja>
References: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>
 <20170908092236.5sl5fc6jp3sleqbw@nataraja>
Message-ID: <CANWiJYjGo23dKktnwXHY1Cc+xo+VL7Gb5YdpBHy8YRLArOmC3Q@mail.gmail.com>

Dear Harald,
Thanks for your reply and respons.

here are the log details on pcap attached for abis and gsmtap also the
configuration on zip that I manage from osmogsmtester.
hope I just miss something.

with deep appreciate and thanks,
Sandi

On Fri, Sep 8, 2017 at 4:22 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sandi,
>
> On Thu, Sep 07, 2017 at 01:05:47PM +0700, Sandi Suhendro wrote:
> > anyone can help me, Im using osmo-gsm-tester osmo-bts.cfg and openbsc.cfg
>
> Where are your detailed log files and the related PCAP files of abis and
> Um/GSMTAP?
>
> Please see https://media.ccc.de/v/osmocon17-4008-reporting_and_
> investigating_issues_in_osmocom for a tutorial
> on how to best report issues.
>
> We want to help, but we need reliable information to determine what's
> happening.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>



-- 
best regards,
Krazy Sandi
Blue Soho Recordings
Number One Recordings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170908/f93913cb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmogsmtester wont register.zip
Type: application/zip
Size: 1329210 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170908/f93913cb/attachment.zip>

From msuraev at sysmocom.de  Fri Sep  8 11:11:18 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 8 Sep 2017 13:11:18 +0200
Subject: OsmoBTS after NITB split
In-Reply-To: <20170907190450.eyexvw6x362ttf3r@nataraja>
References: <c686b9a7-3873-3967-7415-e7f4dba530fc@sysmocom.de>
 <20170907190450.eyexvw6x362ttf3r@nataraja>
Message-ID: <9f99abed-fdb5-e39e-fa4b-24068793c028@sysmocom.de>

On 07.09.2017 21:04, Harald Welte wrote:
> But then, I guess we have more important work than to refactor something that has
> worked for more than 5 years :/

Just to make sure we won't forget the details in 5 years I've created
https://osmocom.org/issues/2508.

>
> I think it could be done at any time, osmo-bsc.git is ready.

Unfortunately not. The OsmoBSC headers were renamed to ".../bsc/gsm_data_shared.h"
while OsmoBTS explicitly requires "openbsc/gsm_data_shared.h". So it's impossible to
build OsmoBTS against OsmoBSC ATM.

One option would be to include just "gsm_data_shared.h" (without directories) in
OsmoBTS and use "--with-openbsc=" configure option but I have not looked in detail
how much breaks in other places it might cause. Simpler option would be to switch to
new "bsc/gsm_data_shared.h" but it would make it incompatible with legacy OpenBSC
which is still in use in some deployments. We can also add symlink with old name to
OsmoBSC as a temporary workaround until the refactoring for #2508 will take place.

I'm somewhat reluctant to just copy "gsm_data_shared.h" to OsmoBTS as it might
introduce all sorts of problems when OpenBSC and OsmoBSC diverge but it might be an
option too.

What do you think?

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






From keith at rhizomatica.org  Fri Sep  8 11:27:59 2017
From: keith at rhizomatica.org (Keith Whyte)
Date: Fri, 8 Sep 2017 13:27:59 +0200
Subject: virtphy and MT SMS
Message-ID: <cf8643cf-db2a-4383-b663-fe2997131c74@rhizomatica.org>

Hi all!

I just installed and configured osmo-bts-virtual and osmocom-bb with
virtphy.

Let me say - this is brilliant! It's so easy to do such things as
trigger IMSI Attach and Detach - so much easier than entering and
exiting airplane mode or power off/on.

Also, MO sms is a breeze.. I have a script to inject SMS regularly, so I
don't have to turn to the mobile and press buttons with each code change
in my SMS handler, I just make the change and wait for the next SMS to
hit it!

So thanks so much to those responsible for making this happen!

Now, one thing that is failing badly for me right "out-of-the-box" is MT
SMS.

As I am totally new to the osmocom-bb code, I guess the best would be a
ticket with some pcaps, but I thought I would ask first if it is a known
issue?

Basically, BSC is doing this:

DLSMS <0024> gsm_04_11.c:127 GSM4.11 TX [HEX of msg redacted]
DLSMS <0024> gsm0411_smc.c:247 SMC(954) TC1* timeout, retrying...

while on the mobile side:

<0005> gsm48_mm.c:3909 (ms 1) Received 'RR_EST_IND' from RR in state MM
idle (sapi 0)
<0005> gsm48_mm.c:912 new state MM IDLE, normal service -> wait for
network command

Then this repeats:

<0001> gsm48_rr.c:4775 Indicated ta 0 (actual ta 0)
<0001> gsm48_rr.c:4777 Indicated tx_power 19
<0001> gsm48_rr.c:4799 ACCH message type 0x00 unknown.
<0001> gsm48_rr.c:664 MON: f=56 lev=>=-47 snr= 0 ber= 63 LAI=262 42 0001
ID=0000 TA=0 pwr=19 TS=1/1
<0001> gsm48_rr.c:2866 MEAS REP: pwr=19 TA=0 meas-invalid=0
rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0
no-ncell-n 7
<0001> gsm48_rr.c:2161 PAGING ignored, we are not camping.




From axilirator at gmail.com  Fri Sep  8 12:30:05 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 8 Sep 2017 15:30:05 +0300
Subject: GAPK status update
Message-ID: <CAPEnp=bw-gXjQuRhCM-QNoFJ3ztw-b5H0J3Fpg0Mr+eaE0+nFQ@mail.gmail.com>

Dear Osmocom community,

I have been working on GAPK (GSM Audio Packet Knife) for some
time, and now I would like to share some achievements.

Previously GAPK was represented as a single binary that
could be called with some command line arguments in order
to perform required operations. This is only handy for
humans, but not for other programs, which may also need
to perform some format / codec conversations or audio
capture / playback.

One of such programs is the mobile from OsmocomBB project.
Currently, when you're making a voice call, both audio
capture and playback are only possible on the L1 side,
i.e. on a Calypso based phone. Of course, the audio stream
can be redirected via MNCC socket, but this is not what
a regular OsmocomBB user would like to do. Moreover, there
is a lack of AMR codec support.

Also, there is another GNURadio based project named GR-GSM.
In short, this is a set of blocks for GSM signal reception,
demodulation and further processing. At the moment, one has
TCH Full Rate decoding capabilities only. Audio playback is
not supported yet.

Having these projects in my mind, I have got an idea of
creating a shared library from the GAPK source code. And,
a few days ago I was managed to get the audio playback
working in OsmocomBB. I hope, this library will be also
usable for other projects.

Brief list of changes were made:

  - Composed a shared library named libosmogapk
  - All exposed symbols have got an 'osmo_gapk' prefix
  - Added a pkg-config manifest and a symbol export map
  - Integrated the Osmocom logging framework
  - Benchmarking is now disabled by default
  - Processing queue now based on the linuxlist

  - Fixed program exit due to ALSA buffer underrun
  - Fixed ALSA audio playback from file

  - Old gapk application was renamed to 'osmo-gapk'
    and linked against the library
  - Adjusted verbosity level (normal / debug)
  - Fixed I/O combinations (ALSA, RTP, file...) check

All changes could be found at the fixeria/lib branch of GAPK.
I hope to see them merged, and open for discussions ;)


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

From laforge at gnumonks.org  Fri Sep  8 13:05:59 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 8 Sep 2017 15:05:59 +0200
Subject: virtphy and MT SMS
In-Reply-To: <cf8643cf-db2a-4383-b663-fe2997131c74@rhizomatica.org>
References: <cf8643cf-db2a-4383-b663-fe2997131c74@rhizomatica.org>
Message-ID: <20170908130559.5z5xpb2gfrsyv2kt@nataraja>

Hi Keith,

On Fri, Sep 08, 2017 at 01:27:59PM +0200, Keith Whyte wrote:
> I just installed and configured osmo-bts-virtual and osmocom-bb with
> virtphy.
> 
> Let me say - this is brilliant! It's so easy to do such things as
> trigger IMSI Attach and Detach - so much easier than entering and
> exiting airplane mode or power off/on.

Thanks for the praise.  There is of course he limitation that we're testing
Osmocom code with Osmocom code, so a mistake in libosmocore will not break
any such test.  So real hardware is still needed for interoperability and
for thesting PHY/hardware/radio related bits.

> Now, one thing that is failing badly for me right "out-of-the-box" is MT
> SMS.

I haven't tried it.  My first question would be: Does it work with a real
phone and the OsmocomBB layer1 + real BTS?  If yes, then something in virt-phy
or osmo-bts-virtual would be broken.  If it doesn't work there either, then
it seems more like an OsmocomBB layer23/mobile problem.

I'd be very interested in some kind of scripting language bindings for OsmocomBB
so we can run dozens, hundreds or even thousands of OsmocomBB 'mobile' programs
runnung concurrently and control them via scripts to perform certain actions,
such as:
* disable (triggers imsi detach + "shutdown")
* enamble (triggers cell selection + LU (imsi attach)"
* manually trigger periodic LU ("time warp")
* mo-sms
* mt-sms
* ussd
* voice call related actions (at least signaling, for actual voice we first need to extend GSMTAP)

In case anyone would be interested in working on this, I'd be very happy
to hear about it.  As lua is light-weight and embeddable, it might be an
idea to include lua in osmocombb.  Given that we may want to run
thousands of instances, having somehing light-weight would be a good
idea.

The other idea would be to introduce some kind of rpc/api instead of
script language bindings.  That API could then be used by some kind of
controller (which could be a script, e.g. python), and we wouldn't need
as many controller instances as we'd need osmocom-bb 'mobile' instances.

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 Sep  8 13:16:34 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 8 Sep 2017 15:16:34 +0200
Subject: GAPK status update
In-Reply-To: <CAPEnp=bw-gXjQuRhCM-QNoFJ3ztw-b5H0J3Fpg0Mr+eaE0+nFQ@mail.gmail.com>
References: <CAPEnp=bw-gXjQuRhCM-QNoFJ3ztw-b5H0J3Fpg0Mr+eaE0+nFQ@mail.gmail.com>
Message-ID: <20170908131634.fahl5vqfb7gpdudr@nataraja>

Hi Vadim,

On Fri, Sep 08, 2017 at 03:30:05PM +0300, Vadim Yanitskiy wrote:
> Having these projects in my mind, I have got an idea of
> creating a shared library from the GAPK source code. And,
> a few days ago I was managed to get the audio playback
> working in OsmocomBB. I hope, this library will be also
> usable for other projects.

I like this very much. Actually, this could even be used by
something like the new osmo-mgw to have more or less generic transcoding
capabilities for gsm-related codecs as well as PCM / G.711.

comments:
* the new introduced memory allocation could have been done via talloc,
  but since it's just for the non-standard benchmarking case, calloc is
  ok.
* it would be nice to convert all allocations to talloc, like in other
  osmo-* code.  This facilitates memory leak debugging.
* rather than listing all symbols individually, you can also simply
  export osmo_gapk_* with a wilcard.  All non-exported symbols then
  have to avoid that prefix.  I prefer this to long lists of symbols
  that you often forget to update when adding new functions
* assuming you have multiple processing queues in a program in the
  future, each queue should have a user-settable identifier which is
  then used as a prefix in all the logging.

Finally, as a personal wishlist item, I would love to see some unit
tests that create a couple of processing queues, destroy them, check
if the resulting encode/decodes is what was expected, and [if possible?]
even check if allocated memory has been properly cleaned up during
destruction of the processing queue.

Let's see what Sylvain has to say about all of this, it's his creation
after all :)

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


From nhofmeyr at sysmocom.de  Fri Sep  8 20:22:01 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 8 Sep 2017 22:22:01 +0200
Subject: Registering problem on osmo-bts
In-Reply-To: <CANWiJYjGo23dKktnwXHY1Cc+xo+VL7Gb5YdpBHy8YRLArOmC3Q@mail.gmail.com>
References: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>
 <20170908092236.5sl5fc6jp3sleqbw@nataraja>
 <CANWiJYjGo23dKktnwXHY1Cc+xo+VL7Gb5YdpBHy8YRLArOmC3Q@mail.gmail.com>
Message-ID: <20170908202201.GB18080@my.box>

Hi,

the attached pcap includes some OML init followed by 20 Mb of apparently
unrelated UDP packets ... is that supposed to be GSMTAP? My wireshark does not
decode it.

(General request: try to keep attachments to mailing lists as small as
possible. Remember, you are multiplying the size by number of subscribers. Make
it small, and if more than a few dozen kb, it's best to post a link instead.)

What I see is successful OML init, i.e. the NITB successfully registers the
BTS. There is no RSL, i.e. the BTS never comes back with any phones trying to
subscribe, no notion of a Location Updating or anything.

Note that your MCC+MNC of 001-01 is a special "testing" MCC+MNC that some
modems/phones treat specially.

All in all I see nothing that stands out as wrong.

What are the symptoms? Does your phone see the 001-01 network?
Maybe someone else knows better, I don't see anything.

~N


From nhofmeyr at sysmocom.de  Fri Sep  8 22:33:46 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 9 Sep 2017 00:33:46 +0200
Subject: jenkins slave setup and artifact re-use
In-Reply-To: <20170907140926.tou2inpp4w6lyw2j@nataraja>
References: <20170905154218.GA14245@ass40.sysmocom.de>
 <CALQ9Oh3dhD2WWKjayKROx5UP8ZB1_PoOZ+e5_iB1D6+8gr8pMA@mail.gmail.com>
 <20170906130527.vunhiqrakvkfdddb@nataraja>
 <20170906152204.22d64g4p5xwjn3tk@nataraja>
 <CALQ9Oh0ER4jgH8qfQK3hM=hfUjTJ3wDNDi6b3wa=UQsye1etjA@mail.gmail.com>
 <20170906193720.bqgvpleubbxqr5sh@nataraja>
 <20170907045328.GA16047@my.box>
 <20170907140926.tou2inpp4w6lyw2j@nataraja>
Message-ID: <20170908223346.GE18080@my.box>

On Thu, Sep 07, 2017 at 03:34:48PM +0200, Andr? Boddenberg wrote:
> My knowledge about the gsm-tester is quite limited to its manual and I

On the tester, all that we want to do is build (usually current master) and
keep the binaries in the image, so that we can launch them with specific config
files on another computer. That's all we need to know in this context.


> Of course this will work, but afaics it won't suite for gerrit
> verifications. Because docker always takes the latest available base
> image. So if libosmocore image is currently rebuild and didn't finish
> yet, a libosmo-abis docker build, which uses libosmocore as base image
> wouldn't wait until the "new" libosmocore image is built, it would

If a libosmo-abis patch starts building just before the latest merge to
libosmo-core master has finished docker building, it doesn't matter much. The
libosmo-abis patch usually does not depend on libosmocore work that is just
being merged. If it does, the libosmo-abis patch submitter will have to wait
for libosmocore to complete. This is the same as our current gerrit patch
submission works and "a law of nature". It's expected and not harmful.


On Thu, Sep 07, 2017 at 04:09:26PM +0200, Harald Welte wrote:
> this would mean you would have to
> * docker build the libosmocore image to check/update to current master
> * docker build the libosmo-abis image
> * docker run the build for osmo-hlr

* I expect the libosmocore-master jenkins job to docker build the libosmocore
  image whenever a patch was merged.
* The libosmo-abis image simply builds on the last stable libosmocore docker
  image it finds in the hub (what was the generic name for the hub again?).
* In turn osmo-hlr takes the last stable libosmo-abis image and just adds
  building osmo-hlr on top.

Each jenkins job takes exactly one 'FROM' image, builds exactly one git tree,
stores exactly one state in the docker cache.

To be precise, the 'master' build jobs would store the built images in the
docker hub thing, the gerrit build jobs just take the build rc and discard the
image changes (could keep the result in the cache for a short time).


> If this splits up to even more images, you will end up having something
> like 8 'docker build' followed by one 'docker run' in each gerrit job.
> I'm not sure how much of the performance gain we will loose that way.

IIUC, we win tremendously by only 'docker build'ing when something is merged to
master. One goal for the osmo-gem-tester is to anyway have docker images ready
for each project's current master.

> manually having to re-trigger builds in the right
> inverse dependency order in every jenkins job.

I don't see why that is required?

> To avoid complexity and having too maintain too many Dockerfiles, related images, etc.

I accept that.  But I don't have a clear picture in my mind of how it would
look in practice with a joint Dockerfile:

So we have one Dockerfile like
https://git.osmocom.org/docker-playground/tree/osmo-gerrit-libosmo/Dockerfile
which contains all osmo gits.

This file also actually updates from git and builds *all* the various libs when
we update the image.

How does this translate to us wanting to e.g. have one jenkins job verifying
libosmocore, one for libosmo-abis, [...], one for osmo-msc?

Each start out with an image where the very project we want to check is already
built and installed, so we need to actively remove installed files from
/usr/local/{include,lib,bin} first, for only that project under scrutiny. We
can't really rely on 'make uninstall' being correct all the time. How about
using 'stow' that showed up recently? It allows wiping installs separately,
right?


I still see chicken-egg problems: when I run a libosmocore jenkins job, I want
to update the image first.
*) That inherently already may build libosmocore. For a gerrit patch, it
   possibly builds libosmocore master, and I can later introduce the patch. If
   I want to test master though, updating the image already *will* build master,
   which I actually wanted to test; at what stage then do I detect a failure?
   If a 'docker build' failure already counts as failure, then:
*) What if e.g. libosmo-abis fails during image update: does it cause a failure
   to be counted for the libosmocore build job instead? I.e. does an unrelated
   broken libosmo-abis master cross-fire onto non-depending builds?
How do we solve this?


And I see a possibility: say for every libosmocore patch we actually also build
the whole chain and verify that this new libosmocore works with all depending
projects. That way we would detect whether libosmocore breaks builds down the
line in other projects, which we don't do on gerrit level yet.

OTOH then we can't easily introduce a change that needs patches in more than
one repos; so far we e.g.  first change libosmo-sccp (hence temporarily break
the build on osmo-msc), then follow right up with a patch on osmo-msc. When we
always verify all depending projects as well, we'll never get the first
libosmo-sccp patch past the osmo-msc check. To solve we'd need to get both
patches in at the same time.

We could parse the commit message 'Depends:' marker, which would actually be
interesting to explore: We could have only one single process that is identical
for *all* gerrit +V builds across all projects, and wherever a patch is
submitted, it always rebuilds and verifies the whole ecosystem from that
project on downwards to the projects that depend on it. By docker build
arguments we can build with specific git hashes, e.g. one with a new patch, the
others with master.  A "Depends:" commit msg marker could take in N such git
hashes at the same time. Non-trivial to implement, takes more build time
(longest for libosmocore, shorter the farther we go towards leaf projects), but
concept wise quite appealing.

For the osmo-gsm-tester, it's actually ok to have only one image with all
binaries ready in it (and launch it N times if we have to separate networks).
Having separate images per each program is helpful to be able to quickly
rebuild only one binary to a different git hash for debugging, but there are
easy ways to do so also with one joint image.



So... my dream setup is one joint image and one build job for all projects,
rebuilding all dependent projects always, using stow to safely clean up for
re-building, and automatically building 'Depends:' marked patches together.

But it seems to me to be less trouble to manage N separate Dockerfiles that
reference each other and are inherently clean every time.
Is there something I'm missing?

~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/20170909/8a5610a1/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Sep  8 23:04:44 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 9 Sep 2017 01:04:44 +0200
Subject: OsmoBTS after NITB split
In-Reply-To: <9f99abed-fdb5-e39e-fa4b-24068793c028@sysmocom.de>
References: <c686b9a7-3873-3967-7415-e7f4dba530fc@sysmocom.de>
 <20170907190450.eyexvw6x362ttf3r@nataraja>
 <9f99abed-fdb5-e39e-fa4b-24068793c028@sysmocom.de>
Message-ID: <20170908230444.GF18080@my.box>

On Fri, Sep 08, 2017 at 01:11:18PM +0200, Max wrote:
> On 07.09.2017 21:04, Harald Welte wrote:
> > But then, I guess we have more important work than to refactor something that has
> > worked for more than 5 years :/
> 
> Just to make sure we won't forget the details in 5 years I've created
> https://osmocom.org/issues/2508.
> 
> >
> > I think it could be done at any time, osmo-bsc.git is ready.
> 
> Unfortunately not. The OsmoBSC headers were renamed to ".../bsc/gsm_data_shared.h"
> while OsmoBTS explicitly requires "openbsc/gsm_data_shared.h". So it's impossible to
> build OsmoBTS against OsmoBSC ATM.

The idea is to not depend on any header file outside of the osmo-bts.git tree.
On my mental todo list: copy gsm_data_shared.* to osmo-bts.git and discard all
dep on external .h/.c files. In a second pass take a look at data structures
and functions, and drop anything not used by osmo-bts.
But would welcome help there indeed.

> I'm somewhat reluctant to just copy "gsm_data_shared.h" to OsmoBTS as it might
> introduce all sorts of problems when OpenBSC and OsmoBSC diverge but it might be an
> option too.

openbsc.git and osmo-bsc.git by definition will diverge. openbsc.git is
becoming legacy as we speak and should not be a reason to hold back anything
happening on osmo-bsc.git.

osmo-bts.git and osmo-bsc.git are independent entities that have to comply to
Abis to talk to each other. No way really for mere mismatching data structures
to cause havoc when the Abis messages are handled properly, is there?

The move plans of gsm_data_shared to libosmocore.git look nice, but I agree to
just copy for now.

(The same kind of copy has happened for various bits between osmo-msc and
osmo-bsc, and the second pass to drop unnecessary stuff and move dup up the
dependency tree is still pending / ongoing.)

Max, do you have time to take on osmo-bts.git and make it independent from
openbsc.git and osmo-bsc.git? Let me know, otherwise I have to take this on as
well. 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/20170909/47e9e9d3/attachment.bin>

From djks74 at gmail.com  Fri Sep  8 23:52:31 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Sat, 9 Sep 2017 06:52:31 +0700
Subject: Registering problem on osmo-bts
In-Reply-To: <20170908202201.GB18080@my.box>
References: <CANWiJYgd-bLHLb_cEd090=oSHThj=d0QiXQYsM-B-X-gtj+0=w@mail.gmail.com>
 <20170908092236.5sl5fc6jp3sleqbw@nataraja>
 <CANWiJYjGo23dKktnwXHY1Cc+xo+VL7Gb5YdpBHy8YRLArOmC3Q@mail.gmail.com>
 <20170908202201.GB18080@my.box>
Message-ID: <CANWiJYgRHmX310iZe+2R6_4Go0puHQPF-Ytocn9M-VZ4__Ep+Q@mail.gmail.com>

Dear Neels,
I will make sure the file attached is small next time.
MCC-MNC change to others also same and yes I can see the network everytime
I changed it.
but it still wont register.

when I did auth policy closed, I also never get notion for location
updating or something.

regards,
Sandi

On Sat, Sep 9, 2017 at 3:22 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> Hi,
>
> the attached pcap includes some OML init followed by 20 Mb of apparently
> unrelated UDP packets ... is that supposed to be GSMTAP? My wireshark does
> not
> decode it.
>
> (General request: try to keep attachments to mailing lists as small as
> possible. Remember, you are multiplying the size by number of subscribers.
> Make
> it small, and if more than a few dozen kb, it's best to post a link
> instead.)
>
> What I see is successful OML init, i.e. the NITB successfully registers the
> BTS. There is no RSL, i.e. the BTS never comes back with any phones trying
> to
> subscribe, no notion of a Location Updating or anything.
>
> Note that your MCC+MNC of 001-01 is a special "testing" MCC+MNC that some
> modems/phones treat specially.
>
> All in all I see nothing that stands out as wrong.
>
> What are the symptoms? Does your phone see the 001-01 network?
> Maybe someone else knows better, I don't see anything.
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170909/f4cb6067/attachment.htm>

From keith at rhizomatica.org  Sun Sep 10 09:53:14 2017
From: keith at rhizomatica.org (Keith)
Date: Sun, 10 Sep 2017 11:53:14 +0200
Subject: log level everything
Message-ID: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>

Hi Max!

Since? https://gerrit.osmocom.org/#/c/3148/

I am no longer able to individually control log levels in
the vty.

I used to use logging level all everything, then this
allowed me to do such as

logging level smpp fatal (get rid of annoying bind check
every 30 secs)

logging level [category i'm interested in] debug

Now, all I seem to be able to do is turn all categories to a
level with

logging level all debug or logging level all notice.

individual category directives such as logging level pag
fatal make no difference.

What am I missing?

Thanks!

BTW, I get the behaviour I need back by moving your check
below the check for "all"::

diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c
index 01480b1..fb2cab8 100644
--- a/src/vty/logging_vty.c
+++ b/src/vty/logging_vty.c
@@ -213,17 +213,18 @@ DEFUN(logging_level,
??????????????? return CMD_WARNING;
??????? }
?
-?????? if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
-?????????????? vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
-?????????????? return CMD_SUCCESS;
-?????? }
-
??????? /* Check for special case where we want to set
global log level */
??????? if (!strcmp(argv[0], "all")) {
??????????????? log_set_log_level(tgt, level);
??????????????? return CMD_SUCCESS;
??????? }
?
+?????? if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
+?????????????? vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
+?????????????? return CMD_SUCCESS;
+?????? }
+
+
??????? if (category < 0) {
??????????????? vty_out(vty, "Invalid category `%s'%s",
argv[0], VTY_NEWLINE);
??????????????? return CMD_WARNING;



From axilirator at gmail.com  Sun Sep 10 13:52:55 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sun, 10 Sep 2017 16:52:55 +0300
Subject: GAPK status update
In-Reply-To: <20170908131634.fahl5vqfb7gpdudr@nataraja>
References: <CAPEnp=bw-gXjQuRhCM-QNoFJ3ztw-b5H0J3Fpg0Mr+eaE0+nFQ@mail.gmail.com>
 <20170908131634.fahl5vqfb7gpdudr@nataraja>
Message-ID: <CAPEnp=ZYkgeyFWmsBdJyv4Uj6_UZeE9E7Lqme0GgpT31Kj_7+Q@mail.gmail.com>

Hi Harald,

> I like this very much. Actually, this could even be used by
> something like the new osmo-mgw to have more or less
> generic transcoding capabilities for gsm-related codecs
> as well as PCM / G.711.

Thanks for your response! Hope my recent commits would help
to move this forward.

> * it would be nice to convert all allocations to talloc, like in other
>   osmo-* code.  This facilitates memory leak debugging.
> * rather than listing all symbols individually, you can also simply
>   export osmo_gapk_* with a wilcard.  All non-exported symbols then
>   have to avoid that prefix.  I prefer this to long lists of symbols
>   that you often forget to update when adding new functions
> * assuming you have multiple processing queues in a program in the
>   future, each queue should have a user-settable identifier which is
>   then used as a prefix in all the logging.

Done.

Only libgsmhr do use generic malloc / free calls. And I think there
is no reason to link this library against talloc as there is only
one allocation / deallocation cycle.

BTW: what about the 'laforge/mmx' branch?
Does anything prevents us from merging it to the master?

> Finally, as a personal wishlist item, I would love to see some unit
> tests that create a couple of processing queues, destroy them, check
> if the resulting encode/decodes is what was expected, and [if possible?]
> even check if allocated memory has been properly cleaned up during
> destruction of the processing queue.

Yeah, I have this idea too. But I don't have enough time
right now. Will do it as soon as it will be possible.
What do you think about adding GAPK to Gerrit?

Regarding to the proper memory deallocation check, I think it
should be possible via the talloc debugging API.


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

From testtestphone8 at gmail.com  Mon Sep 11 07:19:58 2017
From: testtestphone8 at gmail.com (Testphone Test)
Date: Mon, 11 Sep 2017 11:19:58 +0400
Subject: OpenBSC and OsmocomBB
Message-ID: <CAN-wQzTUxFhd6dXu6G6UJ-a1nF1epR4Wgypx3VS+aLWcV-G+Dg@mail.gmail.com>

Dear List

I am trying to run osmocomBB with motorola c118 with openbsc.I tried to get
openbsc network on my phone it works well and I am able to register on
openbsc network.

But when i try to run osmocomBB with openBSC i am not able to get network.
Also when i run rssi firmware on c118 phone i get network and its working
fine.

I am using default configuration file for OpenBSC and using NanoBTS with
1800Mhz support.


Is there any configuration change is needed in openBSC ?

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170911/94d422a0/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Sep 11 12:24:22 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 11 Sep 2017 14:24:22 +0200
Subject: osmo-gsm-tester modems
In-Reply-To: <8edb76b0-afd3-673f-9f60-a11344150f31@sysmocom.de>
References: <20170907231410.2616846f@lazus.yip> <20170908230812.GG18080@my.box>
 <1454ceac-214e-6d19-5dc9-1149810e8426@sysmocom.de>
 <1c33742d-0f9a-3061-918e-867a64af9470@sysmocom.de>
 <8edb76b0-afd3-673f-9f60-a11344150f31@sysmocom.de>
Message-ID: <20170911122422.GA2168@my.box>

On Mon, Sep 11, 2017 at 11:01:23AM +0200, Pau Espin Pedrol wrote:
> today I found the same issue again in prod (/sierra_2 -> /sierra_4).
> Interestingly, both /sierra_2 and /sierra_3 seem to be using the same
> firmware. dmesg shows again a disconnect from the usb port.

We have this idea of giving the same modem a persistent name on ofono, which
would solve the symptoms, but it's curious why this happens.

I had the watchdog script in place that power cycles the quad modem board and
restarts ofono as soon as the modem names mismatch what we expect. But lynxis
disabled it. The reasoning is that we won't catch ofono errors. That may be
true; my idea was to be able automatically recover ofono without manual
intervention. I guess it all depends on how closely you (lynxis) watch the gsm
testers for failures? Because my focus is not particularly on ofono, and when I
hit a broken situation and need to test things, I will restart ofono and rather
not in-depth investigate the failure; in a dismissive way "come on ofono, do
what I want now." What do you guys think about this?


> I guess only /sierra_2 crashes because it's the first modem in the
> resources.conf list and thus it is usually used in all tests (for instance,
> tests which require only 1 modem), and probably some of the steps done in
> one of those tests is crashing the modem.

Something I thought about before: we could implement a kind of random or round
robin to not always pick the first matching resources in the list. Advantage is
that we would cycle through the hardware and force us to precisely formulate
e.g. modem requirements. The disadvantage is that not every test is run exactly
the same, adding complexity that may obscure analysis. i.e. to reproduce a run
on a particular modem, we would have to somehow clamp that randomness, e.g.
log a random seed at the start and allow passing in a random seed on the
cmdline.

~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/20170911/c4f07e84/attachment.bin>

From pespin at sysmocom.de  Mon Sep 11 12:33:35 2017
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 11 Sep 2017 14:33:35 +0200
Subject: osmo-gsm-tester modems
In-Reply-To: <20170911122422.GA2168@my.box>
References: <20170907231410.2616846f@lazus.yip> <20170908230812.GG18080@my.box>
 <1454ceac-214e-6d19-5dc9-1149810e8426@sysmocom.de>
 <1c33742d-0f9a-3061-918e-867a64af9470@sysmocom.de>
 <8edb76b0-afd3-673f-9f60-a11344150f31@sysmocom.de>
 <20170911122422.GA2168@my.box>
Message-ID: <b1460be8-f258-e14c-8baa-ff13d4cc65dd@sysmocom.de>



On 11/09/17 14:24, Neels Hofmeyr wrote:

> 
> I had the watchdog script in place that power cycles the quad modem board and
> restarts ofono as soon as the modem names mismatch what we expect. But lynxis
> disabled it. The reasoning is that we won't catch ofono errors. That may be
> true; my idea was to be able automatically recover ofono without manual
> intervention. I guess it all depends on how closely you (lynxis) watch the gsm
> testers for failures? Because my focus is not particularly on ofono, and when I
> hit a broken situation and need to test things, I will restart ofono and rather
> not in-depth investigate the failure; in a dismissive way "come on ofono, do
> what I want now." What do you guys think about this?
> 
I think we should auto-restart ofono in prod automatically, as anyway we 
will catch the failure of ofono in one test run in the histogram, and we 
can anaylse it, but then at least we can keep running all next test 
without human intervention (ie. systemctl restart ofono). This way we 
avoid having test fail for a lot of hours and then when restarting ofono 
see that there was a regression introduced in osmo-* and having to 
bisect potentially lots of commits.

For RnD, I think it's fine to have manual intervention, I don't want 
automatic stuff running at the same time I'm running tests because I 
want a controlled environment there.

> 
> Something I thought about before: we could implement a kind of random or round
> robin to not always pick the first matching resources in the list. Advantage is
> that we would cycle through the hardware and force us to precisely formulate
> e.g. modem requirements. The disadvantage is that not every test is run exactly
> the same, adding complexity that may obscure analysis. i.e. to reproduce a run
> on a particular modem, we would have to somehow clamp that randomness, e.g.
> log a random seed at the start and allow passing in a random seed on the
> cmdline.
> 

I also thought about this some time ago, but I think we already have too 
many things being unstable right now, let's not add more instability to 
it. And I think we can invest time in other stuff which may be more 
interesting. Once we run suites in parallel we will start using 
resources more intensively and we we'll have this for free.

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


From msuraev at sysmocom.de  Mon Sep 11 12:47:17 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 11 Sep 2017 14:47:17 +0200
Subject: log level everything
In-Reply-To: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
Message-ID: <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>

Could you please share your complete logging configuration? It's rather hard to guess
how it should behave otherwise.

On 10.09.2017 11:53, Keith wrote:
> Hi Max!
>
> Since  https://gerrit.osmocom.org/#/c/3148/
>
> I am no longer able to individually control log levels in
> the vty.
>
> I used to use logging level all everything, then this
> allowed me to do such as
>
> logging level smpp fatal (get rid of annoying bind check
> every 30 secs)

Have you tried replacing "logging level all everything" with "logging level all
debug" or some other logging level?

Also, feel free to contribute to https://osmocom.org/issues/71 your ideas on how it
should behave or how better/simpler/more convenient configuration should look like.

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






From keith at rhizomatica.org  Mon Sep 11 18:27:31 2017
From: keith at rhizomatica.org (Keith)
Date: Mon, 11 Sep 2017 20:27:31 +0200
Subject: log level everything
In-Reply-To: <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
Message-ID: <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>



On 11/09/2017 14:47, Max wrote:
> Could you please share your complete logging configuration? It's rather hard to guess
> how it should behave otherwise.
There's nothing to share really.
I'm describing a case that can be reproduced if you take a
default config (touch osmo-nitb.cfg and start it up)
Then open a VTY and do
logging enable.
logging filter all 1
continue to configure logging level per facility as desired...

> Have you tried replacing "logging level all everything" with "logging level all
> debug" or some other logging level?
Then I get ALL facilities logging at debug.
If I do logging level all info notice for example, then I
don't get ANY debug level logging, regardless of any
facility's explicit level.
> Also, feel free to contribute to https://osmocom.org/issues/71 your ideas on how it
> should behave or how better/simpler/more convenient configuration should look like.
Right, I will take it up there. thanks for the pointer to
the ticket.




From laforge at gnumonks.org  Mon Sep 11 18:43:05 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 11 Sep 2017 20:43:05 +0200
Subject: log level everything
In-Reply-To: <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
Message-ID: <20170911184305.x2vw6num63gmc37f@nataraja>

Hi Keith,

On Mon, Sep 11, 2017 at 08:27:31PM +0200, Keith wrote:

> I'm describing a case that can be reproduced if you take a
> default config (touch osmo-nitb.cfg and start it up)
> Then open a VTY and do
> logging enable.
> logging filter all 1
> continue to configure logging level per facility as desired...

Odd. I did not so far observe any broken behavior, I'm using osmocom
programs of current master more or less every day or every second day.

> > Have you tried replacing "logging level all everything" with "logging level all
> > debug" or some other logging level?
> Then I get ALL facilities logging at debug.

You should then get the specific per-subsystem levels you have configured.

> If I do logging level all info notice for example, then I
> don't get ANY debug level logging, regardless of any
> facility's explicit level.

that's correct.  You're basically saying "never log anything below notice". At that point,
it doesn't matter if any subsystem has a lower, more verbose log level.  Instead,
anything that's below notice will be dropped by the global minimum level "notice"
you've configured.

-- 
- 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 Sep 11 19:09:06 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 11 Sep 2017 21:09:06 +0200
Subject: VTY tests still causing build failures
Message-ID: <20170911190906.tibtpcpfhxtbmm7u@nataraja>

Dear all,

for probably about a year (or longer) we have been putting up with VTY
tests which cause builds to break under unclear circumstances.  I personally
believe the probability of a VTY test failing has recently increased again,
and this is barely tolerable anymore.  Often, rebasing/cherry-picking the given
patch one or two times also doesn't work.  Yet, the given patch-under-test
is not even touching anything related to VTY, like
In https://gerrit.osmocom.org/3899 which has failed in
https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2451/ and
https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2454/

I know Neels and others have spend already significant time in the past trying
to resolve this - unsuccessfully.

So I think the situation has reached a point where we should disable the vty
tests, or at least the specific part of the vty tests that is known to break
most frequently.

I definitely want us to have *more* testing, not less.  However, when the test
itself is not stable yet - particularly after that much time - we cannot
have that buggy test delay our development.

I would vote for running those tests regularly (daily, every few hours, you name
it), but not as part of the mandatory build verification for gerrit V+1.

What do others think?

-- 
- 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 Sep 11 20:28:49 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 11 Sep 2017 22:28:49 +0200
Subject: log level everything
In-Reply-To: <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
Message-ID: <20170911202849.GA3869@my.box>

On Mon, Sep 11, 2017 at 08:27:31PM +0200, Keith wrote:
> > Also, feel free to contribute to https://osmocom.org/issues/71 your ideas on how it
> > should behave or how better/simpler/more convenient configuration should look like.
> Right, I will take it up there. thanks for the pointer to
> the ticket.

I've first had a simplified view of logging, and it expanded with OS#71.
I still have on my mental todo list to figure out one day what we actually want
and how to achieve that.

I also once wrote a mail with some improvement suggestions, but never followed
up on all of those. There's a lot in there...
https://lists.osmocom.org/pipermail/openbsc/2017-February/010312.html

I would welcome a comprehensive approach of defining all use cases we want to
support (like temporary reduction of everything to 'notice' level, and then
going back to the precise landscape of fine tuned logging that was in place
before that...) and then figure out how best to provide those with less
confusion and ideally without changing too much.

So if anyone would like to compile an overview, maybe write a wiki page... that
would be nice.

~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/20170911/96d32e7a/attachment.bin>

From keith at rhizomatica.org  Tue Sep 12 08:55:40 2017
From: keith at rhizomatica.org (Keith)
Date: Tue, 12 Sep 2017 10:55:40 +0200
Subject: log level everything
In-Reply-To: <20170911184305.x2vw6num63gmc37f@nataraja>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911184305.x2vw6num63gmc37f@nataraja>
Message-ID: <f598dd8f-e36d-137a-07d9-dcac3229a82e@rhizomatica.org>

On 11/09/2017 20:43, Harald Welte wrote:

> Odd. I did not so far observe any broken behavior, 

I don't know if it is "broken" as it's never been clear what
the behaviour is expected to be.

>> Then I get ALL facilities logging at debug.
> You should then get the specific per-subsystem levels you have configured.

Well, I don't.

This may be overkill, but let me go through it step by step
to illustrate my need, experience, expected behaviour,
actual behaviour.

NOTE! I have my libosmocore patch in my original post on
this thread in place, so I can still do log level all
everything.

I'm going to use log facilities MNCC and DCC as connecting
and disconnecting osmo-sip-connector will log messages at
NOTICE on both those facilities.
I'm bringing up a fresh nitb with empty config file and
database. I will use some logging config commands and then
connect and disconnect the MNCC socket.
In this example I would like to silence the CC message from
gsm_04_08.c and only see MNCC messages from mncc_sock.c
>From the transcript below I hope the issue is obvious.


OpenBSC> enable
OpenBSC# logging enable
OpenBSC# logging level mncc fatal
OpenBSC# logging level cc fatal
OpenBSC# logging level all debug
OpenBSC# logging filter all 1
OpenBSC# <0006> mncc_sock.c:271 MNCC Socket has connection
with external call control application
<0006> mncc_sock.c:84 MNCC Socket has LOST connection
<0001> gsm_04_08.c:469 Clearing all currently active
transactions!!!

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

OpenBSC# logging level all everything
OpenBSC# logging level mncc info
OpenBSC# <0006> mncc_sock.c:271 MNCC Socket has connection
with external call control application
<0006> mncc_sock.c:84 MNCC Socket has LOST connection

Now the subsystem levels were respected, as CC was FATAL,
MNCC was INFO
This is my desired behaviour.

OpenBSC# logging level cc info
OpenBSC# logging level mncc fatal????
OpenBSC# <0001> gsm_04_08.c:469 Clearing all currently
active transactions!!!

Reversed. Levels still respected, good.

OpenBSC# logging level all debug
OpenBSC# <0006> mncc_sock.c:271 MNCC Socket has connection
with external call control application
<0006> mncc_sock.c:84 MNCC Socket has LOST connection
<0001> gsm_04_08.c:469 Clearing all currently active
transactions!!!

Again, Now _everything_ is logging at DEBUG

Just to really really drive the point home:

OpenBSC# logging level all notice
OpenBSC# logging level cc fatal
OpenBSC# logging level mncc fatal
OpenBSC# <0006> mncc_sock.c:271 MNCC Socket has connection
with external call control application
<0006> mncc_sock.c:84 MNCC Socket has LOST connection
<0001> gsm_04_08.c:469 Clearing all currently active
transactions!!!

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

Is it possible that what we need to do here is to continue
to allow "everything" only for subsystem "all"?

It seems odd to me that there is confusion about this as we
should know what the code is doing, right?
For me personally to take this further the next step would
be analysis of the vty code, which I have not looked at all,
and well.. if you guys have doubts about it.. I don't have a
lot of desire to go there and unfortunately there are other
pressing issues I need to work on.
So for now, my workaround is to allow logging level all
everything, as it allows me to get on with what I need to do.

k/





From keith at rhizomatica.org  Tue Sep 12 09:19:42 2017
From: keith at rhizomatica.org (Keith)
Date: Tue, 12 Sep 2017 11:19:42 +0200
Subject: log level everything
In-Reply-To: <20170911202849.GA3869@my.box>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911202849.GA3869@my.box>
Message-ID: <f0b9eec4-d00b-f358-1fb1-e17ba5183cf2@rhizomatica.org>



On 11/09/2017 22:28, Neels Hofmeyr wrote:
>
> up on all of those. There's a lot in there...
> https://lists.osmocom.org/pipermail/openbsc/2017-February/010312.html
Hi Neels!
Yes, there's a lot in there, I have to admit TL;skipped
through the middle once it started getting into a complexity
that is beyond my experience, there I trust you.. you know
what you're doing. :)

In the last section, re logging level all everything. Maybe
it should be called logging level all passthrough, or
logging level all respect or somesuch.

>
> I would welcome a comprehensive approach of defining all use cases we want to
> support (like temporary reduction of everything to 'notice' level, and then
> going back to the precise landscape of fine tuned logging that was in place
> before that...) 
What I think one needs most to avoid is having to type
?logging level subsystem level
for EVERY subsystem, although, as I mentioned at osmocon, I
have written up some expect scripts to open VTYs and do this.
If logging level all notice were to function as a filter
that respects individual subsystem levels, that would be
workable.

> So if anyone would like to compile an overview, maybe write a wiki page... that
> would be nice.
What do you think of allowing logging level all everything
for the moment?



From pablo at gnumonks.org  Tue Sep 12 11:45:43 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Tue, 12 Sep 2017 13:45:43 +0200
Subject: VTY tests still causing build failures
In-Reply-To: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
References: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
Message-ID: <20170912114543.GA5724@salvia>

On Mon, Sep 11, 2017 at 09:09:06PM +0200, Harald Welte wrote:
> Dear all,
> 
> for probably about a year (or longer) we have been putting up with VTY
> tests which cause builds to break under unclear circumstances.  I personally
> believe the probability of a VTY test failing has recently increased again,
> and this is barely tolerable anymore.  Often, rebasing/cherry-picking the given
> patch one or two times also doesn't work.  Yet, the given patch-under-test
> is not even touching anything related to VTY, like
> In https://gerrit.osmocom.org/3899 which has failed in
> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2451/ and
> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2454/
> 
> I know Neels and others have spend already significant time in the past trying
> to resolve this - unsuccessfully.
> 
> So I think the situation has reached a point where we should disable the vty
> tests, or at least the specific part of the vty tests that is known to break
> most frequently.
> 
> I definitely want us to have *more* testing, not less.  However, when the test
> itself is not stable yet - particularly after that much time - we cannot
> have that buggy test delay our development.

If there are no resources / noone with an assignment to actively
maintain this, then it's reasonable to disable it, or at least disable
the tests that are breaking things now.

> I would vote for running those tests regularly (daily, every few hours, you name
> it), but not as part of the mandatory build verification for gerrit V+1.

I think this is fine, so we get fallout later on that we can address
via robots, and make things a bit more agile.

In the Linux kernel, we usually get all these reports from robots
afterwards, so I would say it's reasonable to follow the same
approach.


From dr.blobb at gmail.com  Tue Sep 12 12:25:04 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Tue, 12 Sep 2017 14:25:04 +0200
Subject: RFC: gerrit verifcations as Jenkins Job Builder YAML file
Message-ID: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>

Hi all,


I've created a prototyp'ish JJB YAML file [1] that holds all current
gerrit verification jobs on jenkins.osomocom.org. Holger and Lynxis
suggested to explore this way of managing Jenkins jobs in the "jenkins
build slaves: Rationale for some builds in docker vs. some not?"
thread.

Following differences occurred, while clicking through all gerrit jobs
configurations:

- some jobs using gcc c compiler warnings v3, some v4
- some jobs are verifying drafts, some not
- only two gerrit jobs are allowing concurrent builds

Are these differences wanted? All job differences are commented in the
YAML file. The jobs are deployed on jenkins.blobb.me [2].

What do you think about this approach [1] in general?


Regards,
   Andr?

[1] https://gerrit.osmocom.org/#/c/3911/1
[2] https://jenkins.blobb.me/view/gerrit-JJB/


From anindya.s at toshniwalcontrols.com  Tue Sep 12 12:50:33 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Tue, 12 Sep 2017 18:20:33 +0530
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
Message-ID: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>

Hello,

 I have gone through some of the documentations and now trying to install
osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
confused , can anyone please tell me if I can build just the BSC part and
in order to do that what are the packages that I have to configure.

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

From nhofmeyr at sysmocom.de  Tue Sep 12 23:19:46 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 13 Sep 2017 01:19:46 +0200
Subject: log level everything
In-Reply-To: <f0b9eec4-d00b-f358-1fb1-e17ba5183cf2@rhizomatica.org>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911202849.GA3869@my.box>
 <f0b9eec4-d00b-f358-1fb1-e17ba5183cf2@rhizomatica.org>
Message-ID: <20170912231116.GA24977@my.box>

On Tue, Sep 12, 2017 at 11:19:42AM +0200, Keith wrote:
> What do you think of allowing logging level all everything
> for the moment?

IIRC it was originally me that started the discussion that 'logging level all
everything' is broken and useless; maybe I oversaw something? If it really
solves a non-trivial situation for you, then maybe we should keep it?

In your example it's hard to follow because it's not obvious which log is on
which level ... we can turn on category printing but apparently we can't print
out each log line's level.

  logging print category 1

I guess best basis for discussion is a unit-test like program with three
categories logging on all levels, and different use cases of what should be
visible, showing whether/how we can reach it.

But I have my attention spread across too many cutting edges at the moment; I'd
love to jump right into it, but it wouldn't do justice to the urgency of other
tasks.

~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/20170913/9087985f/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Sep 12 23:41:26 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 13 Sep 2017 01:41:26 +0200
Subject: VTY tests still causing build failures
In-Reply-To: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
References: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
Message-ID: <20170912234126.GB24977@my.box>

On Mon, Sep 11, 2017 at 09:09:06PM +0200, Harald Welte wrote:
> In https://gerrit.osmocom.org/3899 which has failed in
> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2451/ and
> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2454/

This particular failure is due to a VTY change in libosmocore.  I have fixed it
in osmo-bsc.git, and this needs to be applied to openbsc.git as well.
Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab

However, let's decide when we stop developing on openbsc.git. Every patch that
is merged to openbsc.git now needs additional work to be applied to osmo-*.git.

Vice versa, we only need to backport serious fixes to openbsc.git, this is one
of them.

Here is the backport to openbsc.git:
https://gerrit.osmocom.org/3921

> I know Neels and others have spend already significant time in the past trying
> to resolve this - unsuccessfully.

That was the testBSCreload running into "Broken Pipe" errors.

If you see more of those, we may want to disable the testBSCreload:

https://gerrit.osmocom.org/3922

~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/20170913/da349ab6/attachment.bin>

From holger at freyther.de  Wed Sep 13 06:00:06 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 13 Sep 2017 14:00:06 +0800
Subject: RFC: gerrit verifcations as Jenkins Job Builder YAML file
In-Reply-To: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
References: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
Message-ID: <80550DEF-3539-4F9B-8FD5-360495E34A46@freyther.de>


> On 12. Sep 2017, at 20:25, Andr? Boddenberg <dr.blobb at gmail.com> wrote:
> 
> Hi all,


Hey!


> 
> 
> I've created a prototyp'ish JJB YAML file [1] that holds all current
> gerrit verification jobs on jenkins.osomocom.org. Holger and Lynxis
> suggested to explore this way of managing Jenkins jobs in the "jenkins
> build slaves: Rationale for some builds in docker vs. some not?"
> thread.

cool! Do you have an idea of how we could automatically update our
jobs based from this?



> - some jobs using gcc c compiler warnings v3, some v4

Not on purpose but depends on when we created the job?


> - some jobs are verifying drafts, some not

I don't think we want to verify drafts, we rarely use them anyway


> - only two gerrit jobs are allowing concurrent builds

On purpose. E.g. when executing tests that listen on a UDP/TCP/SCTP
port we can't run them concurrently unless the ports are randomized
or somehow virtualize them. In the case of concurrent builds we know
we either don't run system tests or we run them in docker.

holger





From holger at freyther.de  Wed Sep 13 08:08:51 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 13 Sep 2017 16:08:51 +0800
Subject: VTY tests still causing build failures
In-Reply-To: <20170912234126.GB24977@my.box>
References: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
 <20170912234126.GB24977@my.box>
Message-ID: <B6583DCF-4466-4258-9260-643D15C7DA3D@freyther.de>


> On 13. Sep 2017, at 07:41, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 

Hi!


> On Mon, Sep 11, 2017 at 09:09:06PM +0200, Harald Welte wrote:
>> In https://gerrit.osmocom.org/3899 which has failed in
>> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2451/ and
>> https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2454/
> 
> This particular failure is due to a VTY change in libosmocore.  I have fixed it
> in osmo-bsc.git, and this needs to be applied to openbsc.git as well.
> Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab

Great. So the VTY tests found a behavior change and did its job. I think
disabling tests is a slippery slope. Let's assume we would run it daily
and send emails. How likely would it be that n-failures in a row trigger
a question to disable the mail notifications?

We do run into some form of resource limitation and mitigated by reducing
the number of executors (but that is up again). In the past the VTY test
runner forgot to close sockets but we were still running into something.

So either a form of kernel limit (and I couldn't find a MIB counting it)
or something caused by "slow" (as recently pointed out) disk leading to a
slow start of the software under test?



>> I know Neels and others have spend already significant time in the past trying
>> to resolve this - unsuccessfully.
> 
> That was the testBSCreload running into "Broken Pipe" errors.
> 
> If you see more of those, we may want to disable the testBSCreload:


broken pipe still sounds like either we kill the TCP connection before
we want to or the remote process terminated. Could we dump core and check
if these exist at the end of the test run (and check that dumping core in
a container works).


holger

From anindya.s at toshniwalcontrols.com  Wed Sep 13 08:52:01 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Wed, 13 Sep 2017 14:22:01 +0530
Subject: Error after installing openbsc.deb
Message-ID: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>

Hello,

 I have installed the open openbsc.deb but when I am trying to run it using
the command "osmo-bsc" its giving me the following error

<0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
Bootstrapping the network failed. exiting.
full talloc report on 'sccp' (total      1 bytes in   1 blocks)


Please help me solve it.

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

From domi at tomcsanyi.net  Wed Sep 13 09:05:09 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Wed, 13 Sep 2017 11:05:09 +0200 (CEST)
Subject: Error after installing openbsc.deb
In-Reply-To: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
References: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
Message-ID: <EF0FEC5D-F144-435D-BF84-E6BF7DD58787@tomcsanyi.net>

Hi,

Please create the config file according to the wiki and try again.

Cheers,

Domi


2017. szept. 13. d?tummal, 10:52 id?pontban Anindya Sankar Roy <anindya.s at toshniwalcontrols.com> ?rta:

> Hello, 
> 
>  I have installed the open openbsc.deb but when I am trying to run it using the command "osmo-bsc" its giving me the following error 
> 
> <0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
> Bootstrapping the network failed. exiting.
> full talloc report on 'sccp' (total      1 bytes in   1 blocks)
> 
> 
> Please help me solve it.
> 
> Thanks
> Anindya

From anindya.s at toshniwalcontrols.com  Wed Sep 13 09:07:11 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Wed, 13 Sep 2017 14:37:11 +0530
Subject: Error after installing openbsc.deb
In-Reply-To: <EF0FEC5D-F144-435D-BF84-E6BF7DD58787@tomcsanyi.net>
References: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
 <EF0FEC5D-F144-435D-BF84-E6BF7DD58787@tomcsanyi.net>
Message-ID: <CAAj2SE2zdRXQ4o_z1x9YCNRT1wirbyAfmEkqcSenk6+afeg1Og@mail.gmail.com>

Thanks for replying,  can you please share the wiki link.

On 13-Sep-2017 2:35 PM, "Tomcs?nyi, Domonkos" <domi at tomcsanyi.net> wrote:

> Hi,
>
> Please create the config file according to the wiki and try again.
>
> Cheers,
>
> Domi
>
>
> 2017. szept. 13. d?tummal, 10:52 id?pontban Anindya Sankar Roy <
> anindya.s at toshniwalcontrols.com> ?rta:
>
> > Hello,
> >
> >  I have installed the open openbsc.deb but when I am trying to run it
> using the command "osmo-bsc" its giving me the following error
> >
> > <0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
> > Bootstrapping the network failed. exiting.
> > full talloc report on 'sccp' (total      1 bytes in   1 blocks)
> >
> >
> > Please help me solve it.
> >
> > Thanks
> > Anindya
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170913/203bd731/attachment.htm>

From anindya.s at toshniwalcontrols.com  Wed Sep 13 09:37:19 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Wed, 13 Sep 2017 15:07:19 +0530
Subject: Error after installing openbsc.deb
In-Reply-To: <CAAj2SE2zdRXQ4o_z1x9YCNRT1wirbyAfmEkqcSenk6+afeg1Og@mail.gmail.com>
References: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
 <EF0FEC5D-F144-435D-BF84-E6BF7DD58787@tomcsanyi.net>
 <CAAj2SE2zdRXQ4o_z1x9YCNRT1wirbyAfmEkqcSenk6+afeg1Og@mail.gmail.com>
Message-ID: <CAAj2SE1S0a0TZ7o3Grdj2-8x22E3c_XV-fPzCkdtkUjO-0bGWA@mail.gmail.com>

Hello ,

Please share the wiki link you are talking about as I am all confused from
all that I have read till now.

Thanks
Anindya

On Wed, Sep 13, 2017 at 2:37 PM, Anindya Sankar Roy <
anindya.s at toshniwalcontrols.com> wrote:

> Thanks for replying,  can you please share the wiki link.
>
> On 13-Sep-2017 2:35 PM, "Tomcs?nyi, Domonkos" <domi at tomcsanyi.net> wrote:
>
>> Hi,
>>
>> Please create the config file according to the wiki and try again.
>>
>> Cheers,
>>
>> Domi
>>
>>
>> 2017. szept. 13. d?tummal, 10:52 id?pontban Anindya Sankar Roy <
>> anindya.s at toshniwalcontrols.com> ?rta:
>>
>> > Hello,
>> >
>> >  I have installed the open openbsc.deb but when I am trying to run it
>> using the command "osmo-bsc" its giving me the following error
>> >
>> > <0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
>> > Bootstrapping the network failed. exiting.
>> > full talloc report on 'sccp' (total      1 bytes in   1 blocks)
>> >
>> >
>> > Please help me solve it.
>> >
>> > Thanks
>> > Anindya
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170913/ad9e6890/attachment.htm>

From dr.blobb at gmail.com  Wed Sep 13 10:20:28 2017
From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=)
Date: Wed, 13 Sep 2017 06:20:28 -0400
Subject: RFC: gerrit verifcations as Jenkins Job Builder YAML file
In-Reply-To: <80550DEF-3539-4F9B-8FD5-360495E34A46@freyther.de>
References: <CALQ9Oh3z97_tCTgr21fVn4sHMLJ70HGdAa=KkASK8V-77Ss12g@mail.gmail.com>
 <80550DEF-3539-4F9B-8FD5-360495E34A46@freyther.de>
Message-ID: <CALQ9Oh1z-1xRgVOOS=aeqAEV6LoC31=+4M34yhMEbTiF_vbQQw@mail.gmail.com>

Hi,

>> cool! Do you have an idea of how we could automatically update our
>> jobs based from this?

A job that triggers on gerrit post-merge events (osmo-ci) would be my
preferred choice. It's more elegant than polling and every merged
change will be applied in seconds/minutes. Moreover, this job could
also trigger "update-osmo-ci-on-slaves" job as suggested by Max if a
change in the scripts/ folder has been introduced.

Another topic to discuss are the credentials. The JJB allows to
declare them in a file or pass them while invoking job creation. Would
it be "okay" to store them on node(s)? Another way is to declare
credentials in Jenkins global configuration and use the 'mask password
plugin' to no show them in the console log. Furthermore, a dedicated
user with precise permission to deploy jobs is preferrable.

What is your opinion?

>> Not on purpose but depends on when we created the job?

Max already commented on gerrit that this is probably time related and
that the "latest and greatest" version should be used everywhere.


>> I don't think we want to verify drafts, we rarely use them anyway

Okay, then 'draft verification' will be removed from the YAML file.

>> On purpose. E.g. when executing tests that listen on a UDP/TCP/SCTP
>> port we can't run them concurrently unless the ports are randomized
>> or somehow virtualize them. In the case of concurrent builds we know
>> we either don't run system tests or we run them in docker.

Ah true, then the current YAML should be sufficient as it allows each
job to define whether concurrent builds are allowed (default: false).


From nhofmeyr at sysmocom.de  Wed Sep 13 11:02:57 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 13 Sep 2017 13:02:57 +0200
Subject: VTY tests still causing build failures
In-Reply-To: <B6583DCF-4466-4258-9260-643D15C7DA3D@freyther.de>
References: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
 <20170912234126.GB24977@my.box>
 <B6583DCF-4466-4258-9260-643D15C7DA3D@freyther.de>
Message-ID: <20170913110257.GA13204@my.box>

On Wed, Sep 13, 2017 at 04:08:51PM +0800, Holger Freyther wrote:
> > This particular failure is due to a VTY change in libosmocore.  I have fixed it
> > in osmo-bsc.git, and this needs to be applied to openbsc.git as well.
> > Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab
> 
> Great. So the VTY tests found a behavior change and did its job.

Also it has just uncovered that the osmo-nitb VTY's 'nitb' vty node lacked the
default node commands (including 'exit' and 'end'), so it was never really
necessary to leave the 'nitb' node. It always took the parent node's exit/end
command. Fix applied in https://gerrit.osmocom.org/3921, hope it gets +V now,
then we can rebase the other patches onto it.

> I think
> disabling tests is a slippery slope.

About the particular testBSCreload test that apparently still fails sometimes,
and despite extensive digging we never came up with a way to solidify it, I
think that we might be ok with disabling that one. Only that one.

> We do run into some form of resource limitation and mitigated by reducing
> the number of executors (but that is up again). In the past the VTY test
> runner forgot to close sockets but we were still running into something.
> 
> So either a form of kernel limit (and I couldn't find a MIB counting it)
> or something caused by "slow" (as recently pointed out) disk leading to a
> slow start of the software under test?
[...]
> broken pipe still sounds like either we kill the TCP connection before
> we want to or the remote process terminated. Could we dump core and check
> if these exist at the end of the test run (and check that dumping core in
> a container works).

The debug output we've added so far didn't suggest an obvious error. It would
be great to find a solution ... but I feel that other todos are more important
ATM :/

~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/20170913/5d244f5c/attachment.bin>

From keith at rhizomatica.org  Wed Sep 13 11:06:59 2017
From: keith at rhizomatica.org (Keith Whyte)
Date: Wed, 13 Sep 2017 13:06:59 +0200
Subject: log level everything
In-Reply-To: <20170912231116.GA24977@my.box>
References: <c5a4968d-5e80-c4e8-f7ee-4bab3df77dfd@rhizomatica.org>
 <3101cb1c-5282-f82c-fc35-87ed6ab9904d@sysmocom.de>
 <edf3db82-8fee-f3db-f6ad-3d724a5e569a@rhizomatica.org>
 <20170911202849.GA3869@my.box>
 <f0b9eec4-d00b-f358-1fb1-e17ba5183cf2@rhizomatica.org>
 <20170912231116.GA24977@my.box>
Message-ID: <00558f16-ef55-709a-92dd-cec8728a9a8b@rhizomatica.org>



On 13/09/17 01:19, Neels Hofmeyr wrote:
>
> In your example it's hard to follow because it's not obvious which log is on
> which level ... 
Well I chose those to use as examples as they all log to NOTICE.

> But I have my attention spread across too many cutting edges at the moment; I'd
> love to jump right into it, but it wouldn't do justice to the urgency of other
> tasks.
I know the feeling. I am fine for the moment with what I have, in terms
of doing those other tasks I have on.

thanks
k/




From nhofmeyr at sysmocom.de  Wed Sep 13 17:34:40 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 13 Sep 2017 19:34:40 +0200
Subject: VTY tests still causing build failures
In-Reply-To: <20170913110257.GA13204@my.box>
References: <20170911190906.tibtpcpfhxtbmm7u@nataraja>
 <20170912234126.GB24977@my.box>
 <B6583DCF-4466-4258-9260-643D15C7DA3D@freyther.de>
 <20170913110257.GA13204@my.box>
Message-ID: <20170913173440.GC22133@my.box>

On Wed, Sep 13, 2017 at 01:02:57PM +0200, Neels Hofmeyr wrote:
> Also it has just uncovered that the osmo-nitb VTY's 'nitb' vty node lacked the
> default node commands (including 'exit' and 'end'), so it was never really
> necessary to leave the 'nitb' node. It always took the parent node's exit/end

s/necessary/possible

> command. Fix applied in https://gerrit.osmocom.org/3921, hope it gets +V now,
> then we can rebase the other patches onto it.

~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/20170913/abb20282/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Sep 14 00:09:42 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 14 Sep 2017 02:09:42 +0200
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
Message-ID: <20170914000942.GD13204@my.box>

On Tue, Sep 12, 2017 at 06:20:33PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
>  I have gone through some of the documentations and now trying to install
> osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
> confused , can anyone please tell me if I can build just the BSC part and
> in order to do that what are the packages that I have to configure.

Before you build, be aware of the 
https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
that may get you started without even installing a compiler.

If you really want to build:

We have the old/current osmo-bsc in openbsc.git.
There you need to explicitly enable osmo-bsc:
  ./configure --enable-osmo-bsc

We now also have the new osmo-bsc.git where you may build it on its own, but be
aware that it has moved to an actual M3UA SIGTRAN towards the MSC and is
currently not capable of SCCPlite, which the old osmo-bsc supports.

Find more detail at
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

HTH!

~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/20170914/88b3f00e/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Sep 14 00:14:01 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 14 Sep 2017 02:14:01 +0200
Subject: Error after installing openbsc.deb
In-Reply-To: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
References: <CAAj2SE1g=5bDn7GtMt9CZugu6euFfcxBK1dj8PU6pORfgT81+w@mail.gmail.com>
Message-ID: <20170914001401.GE13204@my.box>

On Wed, Sep 13, 2017 at 02:22:01PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
>  I have installed the open openbsc.deb but when I am trying to run it using
> the command "osmo-bsc" its giving me the following error
> 
> <0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
> Bootstrapping the network failed. exiting.
> full talloc report on 'sccp' (total      1 bytes in   1 blocks)

Take an example config file from e.g.
https://git.osmocom.org/openbsc/tree/openbsc/doc/examples/osmo-bsc
or search the osmocom.org redmine.

Pass the config file explicitly, be sure that it exists, and if errors persist
post the complete error message for further questions:

  osmo-bsc -c path/to/your/osmo-bsc.cfg

This should be the easy part.

~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/20170914/aeb824ab/attachment.bin>

From anindya.s at toshniwalcontrols.com  Thu Sep 14 06:55:41 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Thu, 14 Sep 2017 12:25:41 +0530
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <20170914000942.GD13204@my.box>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
Message-ID: <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>

Hello,

 I am getting this error, can anyone tell me what I need to do from
studying the error message

lab at openair4G:~/dev/open-gsm/osmo-bsc$ autoreconf -fi
configure.ac:9: installing './install-sh'
configure.ac:9: installing './missing'
src/ipaccess/Makefile.am: installing './depcomp'
src/libbsc/Makefile.am:16: error: library used but 'RANLIB' is undefined
src/libbsc/Makefile.am:16:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
src/libbsc/Makefile.am:16:   to 'configure.ac' and run 'autoconf' again.
src/libcommon-cs/Makefile.am:16: error: library used but 'RANLIB' is
undefined
src/libcommon-cs/Makefile.am:16:   The usual way to define 'RANLIB' is to
add 'AC_PROG_RANLIB'
src/libcommon-cs/Makefile.am:16:   to 'configure.ac' and run 'autoconf'
again.
src/libcommon/Makefile.am:16: error: library used but 'RANLIB' is undefined
src/libcommon/Makefile.am:16:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
src/libcommon/Makefile.am:16:   to 'configure.ac' and run 'autoconf' again.
src/libfilter/Makefile.am:17: error: library used but 'RANLIB' is undefined
src/libfilter/Makefile.am:17:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
src/libfilter/Makefile.am:17:   to 'configure.ac' and run 'autoconf' again.
src/libtrau/Makefile.am:23: error: library used but 'RANLIB' is undefined
src/libtrau/Makefile.am:23:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
src/libtrau/Makefile.am:23:   to 'configure.ac' and run 'autoconf' again.
src/utils/Makefile.am:114: warning: compiling 'meas_json.c' with per-target
flags requires 'AM_PROG_CC_C_O' in 'configure.ac'
autoreconf: automake failed with exit status: 1


Thanks
Anindya

On Thu, Sep 14, 2017 at 5:39 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Tue, Sep 12, 2017 at 06:20:33PM +0530, Anindya Sankar Roy wrote:
> > Hello,
> >
> >  I have gone through some of the documentations and now trying to install
> > osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
> > confused , can anyone please tell me if I can build just the BSC part and
> > in order to do that what are the packages that I have to configure.
>
> Before you build, be aware of the
> https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
> that may get you started without even installing a compiler.
>
> If you really want to build:
>
> We have the old/current osmo-bsc in openbsc.git.
> There you need to explicitly enable osmo-bsc:
>   ./configure --enable-osmo-bsc
>
> We now also have the new osmo-bsc.git where you may build it on its own,
> but be
> aware that it has moved to an actual M3UA SIGTRAN towards the MSC and is
> currently not capable of SCCPlite, which the old osmo-bsc supports.
>
> Find more detail at
> https://osmocom.org/projects/cellular-infrastructure/wiki/
> Build_from_Source
>
> HTH!
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170914/237da6f8/attachment.htm>

From nhofmeyr at sysmocom.de  Thu Sep 14 15:20:55 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 14 Sep 2017 17:20:55 +0200
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
 <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
Message-ID: <20170914152055.GC3999@my.box>

On Thu, Sep 14, 2017 at 12:25:41PM +0530, Anindya Sankar Roy wrote:
> Hello,
> 
>  I am getting this error, can anyone tell me what I need to do from
> studying the error message
> 
> lab at openair4G:~/dev/open-gsm/osmo-bsc$ autoreconf -fi
> configure.ac:9: installing './install-sh'
> configure.ac:9: installing './missing'
> src/ipaccess/Makefile.am: installing './depcomp'
> src/libbsc/Makefile.am:16: error: library used but 'RANLIB' is undefined
> src/libbsc/Makefile.am:16:   The usual way to define 'RANLIB' is to add
> 'AC_PROG_RANLIB'

'ranlib' is a tool coming from binutils. It should have come with the
build-essential package. It seems the ubuntu dependencies list is incomplete,
please take the debian one from
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source:

  apt-get install build-essential gcc g++ make automake autoconf libtool pkg-config libtalloc-dev libpcsclite-dev libortp-dev libsctp-dev libssl-dev libdbi-dev libdbd-sqlite3 libsqlite3-dev libpcap-dev libc-ares-dev sqlite3

Would be great if you could confirm that this list works, then we can update
the wiki.

Otherwise, ubuntu 14 is quite old by now. You may want to use a newer one. We
build our binary packes for 16.04, 16.10 and 17.04, as well as Debian 8 and 9.
https://build.opensuse.org/project/show/network:osmocom:nightly

~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/20170914/67204c04/attachment.bin>

From tufanpc at gmail.com  Fri Sep 15 07:52:08 2017
From: tufanpc at gmail.com (mohammad nejati)
Date: Fri, 15 Sep 2017 12:22:08 +0430
Subject: osmo-ntib and osmo-bts-trx config file error
Message-ID: <CAL4AEb8Phg8SM60fn8JLjwBdiknqub5xuH3X2+JTo1+y7SohgQ@mail.gmail.com>

Hi ,

OsmoBTS version 0.6.0.6-ae13
OpenBSC version 0.15.0.885-968a6

I flow the instructions from wiki page and create config files :

https://osmocom.org/projects/cellular-infrastructure/wiki/SDR_OsmoTRX_network_from_scratch

but when i run :
osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C
--debug=DRLL:DCC:DMM:DRR:DRSL:DNM

I got this error :

There is no such command.
Error occurred during reading the below line:
 timer t3103 0

<0005> ../../../src/libbsc/bsc_init.c:536 Failed to parse the config
file: '/home/ashtum/.osmocom/open-bsc.cfg'
Reading config failed. Exiting.


Similarly when i run :

osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg


I got :

((*))
  |
 / \ OsmoBTS
There is no such command.
Error occurred during reading the below line:
 fn-advance 20

% rtp bind-ip is now deprecated
Failed to parse the config file: '/home/ashtum/.osmocom/osmo-bts.cfg'


From ron.menez at entropysolution.com  Fri Sep 15 08:03:34 2017
From: ron.menez at entropysolution.com (Ron)
Date: Fri, 15 Sep 2017 08:03:34 +0000
Subject: osmo-nitb / osmo-bsc ms max power dynamic value
Message-ID: <68BB684D-51E9-45E8-8E57-662F3AD060A6@entropysolution.com>

Hi All,

Is there a way to configure the ?ms max power? to a dynamic value depending on the distance of the mobile phone to the base station?

For now, the default value is 12. Meaning, the base station is telling the mobile phone to transmit in the power of 12dBm either the phone is besides the base station or on the edge of the base station.

If not, is there a roadmap on configuring it with a dynamic or auto value?

TIA.

Best Regard,

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




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

From pespin at sysmocom.de  Fri Sep 15 08:24:30 2017
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 15 Sep 2017 10:24:30 +0200
Subject: osmo-ntib and osmo-bts-trx config file error
In-Reply-To: <CAL4AEb8Phg8SM60fn8JLjwBdiknqub5xuH3X2+JTo1+y7SohgQ@mail.gmail.com>
References: <CAL4AEb8Phg8SM60fn8JLjwBdiknqub5xuH3X2+JTo1+y7SohgQ@mail.gmail.com>
Message-ID: <d6cf0e1c-df5e-71d2-4a9b-f09e8eb5d8e8@sysmocom.de>



On 15/09/17 09:52, mohammad nejati wrote:
> Hi ,
> 
> OsmoBTS version 0.6.0.6-ae13
> OpenBSC version 0.15.0.885-968a6
> 
> I flow the instructions from wiki page and create config files :
> 
> https://osmocom.org/projects/cellular-infrastructure/wiki/SDR_OsmoTRX_network_from_scratch
> 
> but when i run :
> osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C
> --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
> 
> I got this error :
> 
> There is no such command.
> Error occurred during reading the below line:
>   timer t3103 0
> 
> <0005> ../../../src/libbsc/bsc_init.c:536 Failed to parse the config
> file: '/home/ashtum/.osmocom/open-bsc.cfg'
> Reading config failed. Exiting.
> 

I think there was a change a few weeks ago which prevents configuration 
to set any timer to 0. I think you are safe removing that line and 
trying again, and as far as I know the program will provide a sane timer 
value.


> 
> Similarly when i run :
> 
> osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg
> 
> 
> I got :
> 
> ((*))
>    |
>   / \ OsmoBTS
> There is no such command.
> Error occurred during reading the below line:
>   fn-advance 20
> 
> % rtp bind-ip is now deprecated
> Failed to parse the config file: '/home/ashtum/.osmocom/osmo-bts.cfg'
> 

According to osmo-bts code:
"osmotrx fn-advance <0-30>"
So I'd say you need something like this:
phy 0
   osmotrx fn-advance 20

The config from that wiki page seems old and not matching the current 
schema. Please have a look at an up to date config and merge it with the 
required bits to work with your hardware: 
https://git.osmocom.org/osmo-bts/tree/doc/examples/trx/osmo-bts.cfg

Feel free to update the wiki or provide here a working config once you 
are successful.

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


From laforge at gnumonks.org  Fri Sep 15 08:53:16 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 15 Sep 2017 16:53:16 +0800
Subject: osmo-nitb / osmo-bsc ms max power dynamic value
In-Reply-To: <68BB684D-51E9-45E8-8E57-662F3AD060A6@entropysolution.com>
References: <68BB684D-51E9-45E8-8E57-662F3AD060A6@entropysolution.com>
Message-ID: <20170915085316.xnosv5a7lktyfvuw@nataraja>

Hi Ron,

On Fri, Sep 15, 2017 at 08:03:34AM +0000, Ron wrote:
> Is there a way to configure the ?ms max power? to a dynamic value
> depending on the distance of the mobile phone to the base station?

The "ms max power" is the maximum RF power that is used by the MS for
the RACH burst.  It is impossible to know the distance of the MS at
that time.

> For now, the default value is 12. Meaning, the base station is telling
> the mobile phone to transmit in the power of 12dBm either the phone is
> besides the base station or on the edge of the base station.

I think you're confusing the uplink transmit power control loop during
active dedicated channels with the maximum power used during RACH.

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 anindya.s at toshniwalcontrols.com  Fri Sep 15 11:36:40 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Fri, 15 Sep 2017 17:06:40 +0530
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <20170914152055.GC3999@my.box>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
 <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
 <20170914152055.GC3999@my.box>
Message-ID: <CAAj2SE0f+qV-1q0yKHTPFWzT-f8uZN7-HjyxWde7q89=Q3U-vg@mail.gmail.com>

Hello,

 No , I have installed all the packages but still gives the same error.. I
think maybe upgrading to 16.04  might help... I will retry and repost if
getting it to 16.04 solves the problem.

Thanks
Anindya

On Thu, Sep 14, 2017 at 8:50 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Thu, Sep 14, 2017 at 12:25:41PM +0530, Anindya Sankar Roy wrote:
> > Hello,
> >
> >  I am getting this error, can anyone tell me what I need to do from
> > studying the error message
> >
> > lab at openair4G:~/dev/open-gsm/osmo-bsc$ autoreconf -fi
> > configure.ac:9: installing './install-sh'
> > configure.ac:9: installing './missing'
> > src/ipaccess/Makefile.am: installing './depcomp'
> > src/libbsc/Makefile.am:16: error: library used but 'RANLIB' is undefined
> > src/libbsc/Makefile.am:16:   The usual way to define 'RANLIB' is to add
> > 'AC_PROG_RANLIB'
>
> 'ranlib' is a tool coming from binutils. It should have come with the
> build-essential package. It seems the ubuntu dependencies list is
> incomplete,
> please take the debian one from
> https://osmocom.org/projects/cellular-infrastructure/wiki/
> Build_from_Source:
>
>   apt-get install build-essential gcc g++ make automake autoconf libtool
> pkg-config libtalloc-dev libpcsclite-dev libortp-dev libsctp-dev libssl-dev
> libdbi-dev libdbd-sqlite3 libsqlite3-dev libpcap-dev libc-ares-dev sqlite3
>
> Would be great if you could confirm that this list works, then we can
> update
> the wiki.
>
> Otherwise, ubuntu 14 is quite old by now. You may want to use a newer one.
> We
> build our binary packes for 16.04, 16.10 and 17.04, as well as Debian 8
> and 9.
> https://build.opensuse.org/project/show/network:osmocom:nightly
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170915/284b4bb0/attachment.htm>

From nhofmeyr at sysmocom.de  Fri Sep 15 13:15:13 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 15 Sep 2017 15:15:13 +0200
Subject: vty: indent to exit, side effect
Message-ID: <20170915131513.GA18369@my.box>

I implemented https://gerrit.osmocom.org/3880 to use indenting for vty implicit
'exit'.

There's one thing I'm sneaking in there though which I'd like to mention before
I merge:

The patch is storing vty parent node state. This state not only stores previous
indenting, but it also stores the parent's 'node' id and 'priv' data (the
node's object), and puts these back in place after going to a parent.

So far our go_parent_cb()s set these, and AFAIK all of them simply put the
parent's exact node and priv pointer back in place. But technically, a
go_parent_cb() *could* do some magic like going to a completely different node,
or re-creating a new priv pointer. By overwriting from stored state, we will
override such behavior.

I think we want this to happen from stored state in the future, and drop most
of the go_parent_cb(). Does everyone agree?

~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/20170915/94df355d/attachment.bin>

From phippsr at cs.washington.edu  Fri Sep 15 18:05:44 2017
From: phippsr at cs.washington.edu (Rowan Phipps)
Date: Fri, 15 Sep 2017 18:05:44 +0000
Subject: OpenBSC USSD external application
In-Reply-To: <CA+QHiD9_Bv72JyTpB40UD5z=dZGwFud5SsPdkHS7iaV24+FiJQ@mail.gmail.com>
References: <CA+YA_XSaAv5U1utUuESDJi=D8Fk8wyEBFo0G+rCXGBAgkn_kLA@mail.gmail.com>
 <CABmJbFUEn-RjHbTHMcgBZdQ2hZZtn-+Oic8RC2+QRrC7R_jbzg@mail.gmail.com>
 <CA+YA_XQuV3Oo4tkSO+hX4K5jOj_hpfPEze8AW06TfuA13U+D5w@mail.gmail.com>
 <CA+QHiD9_Bv72JyTpB40UD5z=dZGwFud5SsPdkHS7iaV24+FiJQ@mail.gmail.com>
Message-ID: <CA+YA_XS00ZgYBXqdy8hNg+JfsypaQvcOZw9HPLxAjOeEbbs3rw@mail.gmail.com>

Hi,
I tried using those branches with those flags set and they do not compile
together.  Libosmocore builds fine but when building openbsc I get the
following error:
/usr/local/lib/libosmoabis.so: undefined reference to `osmo_timer_setup'

I did manage to get ussd working using libosmocore:master and
openbsc:fairwaves/sup-ussd with some modifications.  I ended up writing my
own sup endpoint since I was having some issues with reg-proxy while trying
to establish a sip session.

After the initial invoke processUnstructuredSS_request send by the phone,
future messages from the phone have a message type less than 0x7b (e.g.
0x3b, 0x7a) and for some reason the phone leaves out the iei, and opcode
from the messages it sends.  This causes problems in gsm0480.c in
libosmocore since the opcode is not set and the data is misaligned due to
the missing iei.  I wrote some workarounds into libosmocore which seem to
fix the problem but I was wondering if anyone else has had similar issues.
I made some other minor modifications to libosmocore to add message type
and component type to the ss_request object.

I also noticed that the max ussd string length is set to 31 bytes in
gsm0480.h.  According to the gsm standards that values should be 160 bytes
or 182 7 bit characters.  Is there any reason for it to be set to 31 or
should it be changed to a larger value?


On Fri, Sep 8, 2017 at 2:16 AM Ivan Kluchnikov <ivan.kluchnikov at fairwaves.co>
wrote:

> Hello Rowan,
>
> You should use:
> for libosmocore: fairwaves/master-rebase branch
> for openbsc: fairwaves/master-rebase branch and use
> ./configure --enable-ussd-proxy
>
> 2017-09-07 21:15 GMT+03:00 Rowan Phipps <phippsr at cs.washington.edu>:
>
>> Do you know which version of libosmocore that branch worked with?  I have
>> tried it with both the master branch and the fairwaves/master-rebase branch
>> and neither one compiled.  I also tried rebasing the
>> fairwaves/master-rebase onto master again.  This at least builds but it
>> looks like osmo-nitb is sending a different version of SUP than what
>> libosmocore is expecting and so it can't decode it.  The function in
>> libosmocore that seems to do the decoding is osmo_gsup_decode in gsup.c
>>
>> I have seen references to be SUP and GSUP in the code.  Are these two
>> different protocols or are they the same thing?  Also, are they specified
>> anywhere other than in the code?
>>
>>
>> On Sat, Sep 2, 2017 at 2:11 PM Alexander Chemeris <
>> alexander.chemeris at gmail.com> wrote:
>>
>>> Hi Rowan,
>>>
>>> A more recent version of this work is a part of the
>>> fairwaves/master-rebase branch. It has implementation of exporting
>>> USSD (and any other SS for that matter) over a SUP socket and an
>>> external utility to decode/encode them and convert to/from SIP+XML
>>> similar to defined in the IMS standard.
>>>
>>> We're currently using this code to implement external USSD services
>>> like a balance check from a billing system and also to forward SS and
>>> USSD to MAP/Sigtran. So I think the code should work well for you.
>>>
>>> If you find this code useful, we would greatly appreciate any help in
>>> merging this code into master. We intend to eventually merge this into
>>> master, but it requires some cleanup before it could be submitted for
>>> a review and given it's not a simple small change we've never had
>>> enough time to do that so far :(
>>>
>>> On Wed, Aug 30, 2017 at 10:59 PM, Rowan Phipps
>>> <phippsr at cs.washington.edu> wrote:
>>> > 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
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Alexander Chemeris.
>>> CTO/Founder, Fairwaves, Inc.
>>> https://fairwaves.co
>>>
>> --
>> Thanks!
>>     - Rowan Phipps
>>
>
> --
Thanks!
    - Rowan Phipps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170915/7fad45a3/attachment.htm>

From ron.menez at entropysolution.com  Sun Sep 17 12:16:39 2017
From: ron.menez at entropysolution.com (Ron)
Date: Sun, 17 Sep 2017 12:16:39 +0000
Subject: osmo-bsc integration to osmo-msc
Message-ID: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>

Hi All,

Is there a link on how to integration osmo-bsc to osmo-msc? or osmo-bsc_nat is required to integrate osmo-bsc to osmo-msc?

A config file for both osmo-bsc and osmo-msc that can be shared will be greatly appreciated.

TIA.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170917/814f3a02/attachment.htm>

From laforge at gnumonks.org  Sun Sep 17 13:21:01 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 17 Sep 2017 21:21:01 +0800
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
Message-ID: <20170917132101.5bu3xwg6utqrwbov@nataraja>

On Sun, Sep 17, 2017 at 12:16:39PM +0000, Ron wrote:

> Is there a link on how to integration osmo-bsc to osmo-msc? 

You need osmo-stp, as both osmo-bsc and osmo-msc implement only an M3UA ASP role.

> or osmo-bsc_nat is required to integrate osmo-bsc to osmo-msc?

no.

> A config file for both osmo-bsc and osmo-msc that can be shared will be greatly appreciated.

Working config files are in the 'doc/examples' folders of the osmo-bsc and osmo-msc repositories.

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


From ron.menez at entropysolution.com  Sun Sep 17 13:45:26 2017
From: ron.menez at entropysolution.com (Ron)
Date: Sun, 17 Sep 2017 13:45:26 +0000
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <20170917132101.5bu3xwg6utqrwbov@nataraja>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
Message-ID: <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>

Thank you very much for the immediate reply Harald.

We?ll be trying to install osmo-stp too to integrate both osmo-bsc and osmo-msc.

Best Regard,

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




On Sep 17, 2017, at 9:21 PM, Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> wrote:

On Sun, Sep 17, 2017 at 12:16:39PM +0000, Ron wrote:

Is there a link on how to integration osmo-bsc to osmo-msc?

You need osmo-stp, as both osmo-bsc and osmo-msc implement only an M3UA ASP role.

or osmo-bsc_nat is required to integrate osmo-bsc to osmo-msc?

no.

A config file for both osmo-bsc and osmo-msc that can be shared will be greatly appreciated.

Working config files are in the 'doc/examples' folders of the osmo-bsc and osmo-msc repositories.

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

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

From laforge at gnumonks.org  Sun Sep 17 14:06:00 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 17 Sep 2017 22:06:00 +0800
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
Message-ID: <20170917140600.tsb2eem3tmn7xh7z@nataraja>

On Sun, Sep 17, 2017 at 01:45:26PM +0000, Ron wrote:
> We?ll be trying to install osmo-stp too to integrate both osmo-bsc and osmo-msc.

FYI: It's part of the libosmo-sccp.git repository.  It also contains an example config
file.  If you start all three programs on the same machine with the
included example program files, they should find each other.

Documentation is still not produced yet.  This new "post NITB"
architecture is too recent.  It's basically the "osmocom bleeding edge"
and it will take another couple of weeks (expected) until there's the
corresponding user manuals.

After manuals have been created and all related wiki pages
updated/created, we will officially "deprecate" OsmoNITB development,
which means that new patches will have to be first merged to
OsmoBSC/OsmoMSC, before they can be back-ported to OsmoNITB.  We'll also
likely only accept bug fixes for legacy OsmoNITB at that point, while
new features must go to OsmoBSC+OsmoMSC.

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 tufanpc at gmail.com  Sun Sep 17 16:17:00 2017
From: tufanpc at gmail.com (mohammad nejati)
Date: Sun, 17 Sep 2017 20:47:00 +0430
Subject: Osmo-trx build problem
Message-ID: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>

Hi ,
i?m trying to build osmo-trx master branch .

What i?am doing :
autoreconf -i
./configure
make

In make step i get this error :

Evaluating ?parse? option: ?(?P\d+).(?P\d+).(?P\d+)? does not parse
current version 'P2.8TRUNK?
usage: bumpversion [-h] [?config-file FILE] [?verbose] [?list]
[?allow-dirty] [?parse REGEX] [?serialize FORMAT]
[?search SEARCH] [?replace REPLACE]
[?current-version VERSION] [?dry-run] --new-version
VERSION [?commit | --no-commit] [?tag | --no-tag]
[?tag-name TAG_NAME] [?message COMMIT_MSG]
part [file [file ?]]
bumpversion: error: the following arguments are required: --new-version
make all-recursive


From nhofmeyr at sysmocom.de  Mon Sep 18 00:38:32 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 18 Sep 2017 02:38:32 +0200
Subject: Osmo-trx build problem
In-Reply-To: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
References: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
Message-ID: <20170918003832.GB11540@my.box>

Hi Mohammad,

I hope that Max has some more on this, but AFAIK the 'bumpversion' part has
been added recently as part of the "release helper from libosmocore", currently
osmo-trx's last master revision.

As a workaround until the problem is clear, you could try to revert the last
master revision and try rebuilding with that:

  git revert 099a44abfbe9f573ae553ba24945ef452c9982b8
  autoreconf -fi
  ./configure
  make

'bumpversion' has been discussed elsewhere, with an indication that we may want
to remove this dependency again. It should anyway just be needed for making a
release, I'm not sure why this appears during normal build from source.

~N


On Sun, Sep 17, 2017 at 08:47:00PM +0430, mohammad nejati wrote:
> Hi ,
> i?m trying to build osmo-trx master branch .
> 
> What i?am doing :
> autoreconf -i
> ./configure
> make
> 
> In make step i get this error :
> 
> Evaluating ?parse? option: ?(?P\d+).(?P\d+).(?P\d+)? does not parse
> current version 'P2.8TRUNK?
> usage: bumpversion [-h] [?config-file FILE] [?verbose] [?list]
> [?allow-dirty] [?parse REGEX] [?serialize FORMAT]
> [?search SEARCH] [?replace REPLACE]
> [?current-version VERSION] [?dry-run] --new-version
> VERSION [?commit | --no-commit] [?tag | --no-tag]
> [?tag-name TAG_NAME] [?message COMMIT_MSG]
> part [file [file ?]]
> bumpversion: error: the following arguments are required: --new-version
> make all-recursive

-- 
- 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/20170918/be6c2511/attachment.bin>

From msuraev at sysmocom.de  Mon Sep 18 09:07:59 2017
From: msuraev at sysmocom.de (Max)
Date: Mon, 18 Sep 2017 11:07:59 +0200
Subject: Osmo-trx build problem
In-Reply-To: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
References: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
Message-ID: <17701233-9224-a7ef-db53-31d942f89dfb@sysmocom.de>

That's odd - I've seen this error message but it never prevented the binaries from
being built. That's why I haven't come around to fixing this yet.

Could you please attach the complete output of 'make' command and your config.log?

On 17.09.2017 18:17, mohammad nejati wrote:
> Evaluating ?parse? option: ?(?P\d+).(?P\d+).(?P\d+)? does not parse
> current version 'P2.8TRUNK?
> usage: bumpversion [-h] [?config-file FILE] [?verbose] [?list]
> [?allow-dirty] [?parse REGEX] [?serialize FORMAT]
> [?search SEARCH] [?replace REPLACE]
> [?current-version VERSION] [?dry-run] --new-version
> VERSION [?commit | --no-commit] [?tag | --no-tag]
> [?tag-name TAG_NAME] [?message COMMIT_MSG]
> part [file [file ?]]
> bumpversion: error: the following arguments are required: --new-version
> make all-recursive


-- 
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 ron.menez at entropysolution.com  Mon Sep 18 09:37:39 2017
From: ron.menez at entropysolution.com (Ron)
Date: Mon, 18 Sep 2017 09:37:39 +0000
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <20170917140600.tsb2eem3tmn7xh7z@nataraja>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
Message-ID: <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>

Hi Harald,

Installed the osmo-stp in the same machine with osmo-msc and osmo-bsc but unfortunately, osmo-bsc logs still shows connection timeout and tries to reconnect again.

<000a> bsc_msc.c:278 Attempting to reconnect to the MSC()
<000a> bsc_msc.c:271 Attempting to reconnect to the MSC().
<000a> bsc_msc.c:171 Attempting to connect MSC() at 192.168.100.11:6666
<000a> bsc_msc.c:211 MSC() Connection in progress
<000a> bsc_msc.c:67 MSC() Connection timeout.
<000a> osmo_bsc_msc.c:391 Lost MSC connection. Freing stuff.

We used the config files from the "doc/examples? folder.

We also tried to change the IP address from the local IP and 127.0.0.1 but still the same issue.

I?m not sure if my osmo-msc and osmo-bsc is out-dated but we also tried to get an updated version of both osmo-msc and osmo-bsc. Still we were unable to install it correctly. We have the following error:

Errors:
osmo-msc:
configure: error: Package requirements (libosmo-mgcp-client >= 1.0.0) were not met:

No package 'libosmo-mgcp-client? found

osmo-bsc:
configure: error: Package requirements (libosmo-legacy-mgcp >= 0.0.1) were not met:

No package 'libosmo-legacy-mgcp' found

I?m checking what package to install but unfortunately, those package requirements is unavailable from the nightly-build and from the git repo.

Best Regard,

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



On Sep 17, 2017, at 10:06 PM, Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> wrote:

On Sun, Sep 17, 2017 at 01:45:26PM +0000, Ron wrote:
We?ll be trying to install osmo-stp too to integrate both osmo-bsc and osmo-msc.

FYI: It's part of the libosmo-sccp.git repository.  It also contains an example config
file.  If you start all three programs on the same machine with the
included example program files, they should find each other.

Documentation is still not produced yet.  This new "post NITB"
architecture is too recent.  It's basically the "osmocom bleeding edge"
and it will take another couple of weeks (expected) until there's the
corresponding user manuals.

After manuals have been created and all related wiki pages
updated/created, we will officially "deprecate" OsmoNITB development,
which means that new patches will have to be first merged to
OsmoBSC/OsmoMSC, before they can be back-ported to OsmoNITB.  We'll also
likely only accept bug fixes for legacy OsmoNITB at that point, while
new features must go to OsmoBSC+OsmoMSC.

Regards,
Harald

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170918/281b4e62/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-stp.cfg
Type: application/octet-stream
Size: 444 bytes
Desc: osmo-stp.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170918/281b4e62/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.cfg
Type: application/octet-stream
Size: 2250 bytes
Desc: osmo-bsc.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170918/281b4e62/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-msc.cfg
Type: application/octet-stream
Size: 325 bytes
Desc: osmo-msc.cfg
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170918/281b4e62/attachment-0002.obj>

From nhofmeyr at sysmocom.de  Mon Sep 18 11:50:49 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 18 Sep 2017 13:50:49 +0200
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
Message-ID: <20170918115049.GA1618@my.box>

Hi Ron,

about the libosmo-*mgcp* issues: apologies for your inconvenience, you are
hitting a time of active migration, with short periods of things getting out of
sync and breaking.

The osmo-msc package is currently still failing the builds after renames in
libosmo-mgcp* (osmo-mgw.git) caused some fallout in the debian packaging. Most
things have been fixed, the hopefully last patch is already in gerrit.
https://gerrit.osmocom.org/3971
Will hopefully fix and merge that today and then kick off another debian
packages build.

However, looking at
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
you should be able to install osmo-bsc, only osmo-msc should fail.
Wild guess: update the package repositories? (apt-get update)

About the osmo-stp connections, I'd first like to make sure that you are aware:
the old SCCPlite VTY commands may still be present but have no effect. The
connection to osmo-stp is handled by the new SIGTRAN library from libosmo-sccp.

If you'd like to change the setting where to reach osmo-stp, it looks like this:
https://git.osmocom.org/osmo-bsc/plain/doc/examples/osmo-bsc/osmo-bsc_custom-sccp.cfg
particularly:

cs7 instance 0
 point-code 0.42.1
 asp asp-clnt-OsmoBSC 2905 0 m3ua
  ! where to reach the STP
  remote-ip 10.23.24.1

I am puzzled by this log output:
> <000a> bsc_msc.c:171 Attempting to connect MSC() at 192.168.100.11:6666
since it indicates an attempt to connect the old way, but I see that this is
code left behind from before the new SIGTRAN, which should instead connect on
port 2905. Added to the list of things we need to revisit.


Documentation on the new setup is pending. Let me break down how I run things:

osmo-stp.cfg:
---
cs7 instance 0
 xua rkm routing-key-allocation dynamic-permitted
 listen m3ua 2905
 accept-asp-connections dynamic-permitted
---

osmo-stp -c osmo-stp.cfg

Make sure you start osmo-stp first (should be able to handle any startup order
in the future, but for now, to make sure).


osmo-msc.cfg:
---
network
 network country code 901
 mobile network code 98
 short name OsmoMSC
 long name OsmoMSC
 auth policy closed
 location updating reject cause 13
 encryption a5 0
 rrlp mode none
 mm info 1
msc
 mgcpgw remote-ip 192.168.0.132
---

optionally add
---
cs7 instance 0
 point-code 0.0.1
msc
 cs7-instance-iu 0
 cs7-instance-a 0
---

osmo-msc -c osmo-msc.cfg


osmo-bsc.cfg:
---
network
 network country code 901
 mobile network code 70
 short name osmo-gsm-tester-msc
 long name osmo-gsm-tester-msc
 auth policy closed
 location updating reject cause 13
 encryption a5 0
 neci 1
 rrlp mode none
 mm info 1
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999
 timer t3101 10
 timer t3109 4
 timer t3113 60
 bts 0
  type sysmobts
  band GSM-1800
  cell_identity 0
  location_area_code 23
  training_sequence_code 7
  base_station_id_code 63
  ms max power 33
  cell reselection hysteresis 4
  rxlev access min 0
  channel allocator ascending
  rach tx integer 9
  rach max transmission 7
  ip.access unit_id 1800 0
  oml ip.access stream_id 255 line 0
  gprs mode none
  neighbor-list mode manual
  si2quater neighbor-list add uarfcn 9800 401 0
  trx 0
   rf_locked 0
   arfcn 868
   nominal power 23
   max_power_red 21
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
   timeslot 1
    phys_chan_config SDCCH8
   timeslot 2
    phys_chan_config TCH/H
   timeslot 3
    phys_chan_config TCH/H
   timeslot 4
    phys_chan_config TCH/H
   timeslot 5
    phys_chan_config TCH/H
   timeslot 6
    phys_chan_config TCH/H
   timeslot 7
    phys_chan_config TCH/H
msc
 token msc_token_23_42
 core-mobile-country-code 901
 core-mobile-network-code 70
 ip.access rtp-base 8000
 timeout-ping 1800
 timeout-ping advanced
 timeout-pong 60
 codec-list hr3
 dest 151.80.237.229 5000 184
 amr-config 12_2k forbidden
 amr-config 10_2k forbidden
 amr-config 7_95k forbidden
 amr-config 7_40k forbidden
 amr-config 6_70k forbidden
 amr-config 5_90k allowed
 amr-config 5_15k forbidden
 amr-config 4_75k forbidden
---

osmo-bsc -c osmo-bsc.cfg

Above config assumes defaults, a full M3UA/SCCP config would look like

---
cs7 instance 1
 point-code 0.42.0
 asp asp-clnt-msc-0 2905 0 m3ua
 as as-clnt-msc-0 m3ua
  asp asp-clnt-msc-0
  routing-key 2 0.42.0
 sccp-address bsc_local
  routing-indicator PC
  point-code 0.42.0
 sccp-address msc_remote
  routing-indicator PC
  point-code 0.0.1
msc 0
 bsc-addr bsc_local
 msc-addr msc_remote
---


Upon startup, I see e.g. osmo-bsc logs like

20170918133916790 DLINP <0002> ../../../src/libosmo-netif/src/stream.c:558 accept()ed new link from 127.0.0.1 to port 2905
20170918133916790 DLSS7 <000c> ../../../src/libosmo-sccp/src/osmo_ss7.c:1606 (r=127.0.0.1:50020<->l=127.0.0.1:2905): New m3ua connection accepted
20170918133916790 DLSS7 <000c> ../../../src/libosmo-sccp/src/osmo_ss7.c:1642 (r=127.0.0.1:50020<->l=127.0.0.1:2905): created dynamicASP asp-dyn-1


Looking through this, I see various bits that still need polishing, but the
current osmo-bsc,stp,msc setup should work as it is.

I hope you will get a working setup going with this information, and once the
osmo-msc debian builds again.

Thanks for reporting!

~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/20170918/a4b382ef/attachment.bin>

From menezer at gmail.com  Tue Sep 19 05:18:44 2017
From: menezer at gmail.com (Bob Skie)
Date: Tue, 19 Sep 2017 13:18:44 +0800
Subject: OSMO-BSC integration to other MSC
Message-ID: <FECB6503-49B9-4EF6-BC6E-0D065F9E80A3@gmail.com>

Hi All,

Good day.

If we are going to integrate OSMO-BSC to another MSC, for example, a Huawei MSC, what components do we need?

Is their a link that can help us do this task?

Thank you in advance.

BR,

Bob

From ron.menez at entropysolution.com  Tue Sep 19 08:34:16 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 19 Sep 2017 08:34:16 +0000
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <20170918115049.GA1618@my.box>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
 <20170918115049.GA1618@my.box>
Message-ID: <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>

Hi Neel,

Thanks for the detailed info.

But we are using Ubuntu 16.10 as our OS.

Can we still used the nightly package for Debian?

We tried to install the osmo-bsc but it has an unmet dependencies ?libssl1.1?. This seems not available in Ubuntu.

BTW, we are hoping to have the git version instead of the nightly package. We are also exploring in doing some development on our side.

Is there an available git version of osmo-bsc, osmo-stp, osmo-msc and osmo-hlr that we can download?

Best Regard,

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




On Sep 18, 2017, at 7:50 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote:

Hi Ron,

about the libosmo-*mgcp* issues: apologies for your inconvenience, you are
hitting a time of active migration, with short periods of things getting out of
sync and breaking.

The osmo-msc package is currently still failing the builds after renames in
libosmo-mgcp* (osmo-mgw.git) caused some fallout in the debian packaging. Most
things have been fixed, the hopefully last patch is already in gerrit.
https://gerrit.osmocom.org/3971
Will hopefully fix and merge that today and then kick off another debian
packages build.

However, looking at
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
you should be able to install osmo-bsc, only osmo-msc should fail.
Wild guess: update the package repositories? (apt-get update)

About the osmo-stp connections, I'd first like to make sure that you are aware:
the old SCCPlite VTY commands may still be present but have no effect. The
connection to osmo-stp is handled by the new SIGTRAN library from libosmo-sccp.

If you'd like to change the setting where to reach osmo-stp, it looks like this:
https://git.osmocom.org/osmo-bsc/plain/doc/examples/osmo-bsc/osmo-bsc_custom-sccp.cfg
particularly:

cs7 instance 0
point-code 0.42.1
asp asp-clnt-OsmoBSC 2905 0 m3ua
 ! where to reach the STP
 remote-ip 10.23.24.1

I am puzzled by this log output:
<000a> bsc_msc.c:171 Attempting to connect MSC() at 192.168.100.11:6666
since it indicates an attempt to connect the old way, but I see that this is
code left behind from before the new SIGTRAN, which should instead connect on
port 2905. Added to the list of things we need to revisit.


Documentation on the new setup is pending. Let me break down how I run things:

osmo-stp.cfg:
---
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
listen m3ua 2905
accept-asp-connections dynamic-permitted
---

osmo-stp -c osmo-stp.cfg

Make sure you start osmo-stp first (should be able to handle any startup order
in the future, but for now, to make sure).


osmo-msc.cfg:
---
network
network country code 901
mobile network code 98
short name OsmoMSC
long name OsmoMSC
auth policy closed
location updating reject cause 13
encryption a5 0
rrlp mode none
mm info 1
msc
mgcpgw remote-ip 192.168.0.132
---

optionally add
---
cs7 instance 0
point-code 0.0.1
msc
cs7-instance-iu 0
cs7-instance-a 0
---

osmo-msc -c osmo-msc.cfg


osmo-bsc.cfg:
---
network
network country code 901
mobile network code 70
short name osmo-gsm-tester-msc
long name osmo-gsm-tester-msc
auth policy closed
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3109 4
timer t3113 60
bts 0
 type sysmobts
 band GSM-1800
 cell_identity 0
 location_area_code 23
 training_sequence_code 7
 base_station_id_code 63
 ms max power 33
 cell reselection hysteresis 4
 rxlev access min 0
 channel allocator ascending
 rach tx integer 9
 rach max transmission 7
 ip.access unit_id 1800 0
 oml ip.access stream_id 255 line 0
 gprs mode none
 neighbor-list mode manual
 si2quater neighbor-list add uarfcn 9800 401 0
 trx 0
  rf_locked 0
  arfcn 868
  nominal power 23
  max_power_red 21
  rsl e1 tei 0
  timeslot 0
   phys_chan_config CCCH+SDCCH4
  timeslot 1
   phys_chan_config SDCCH8
  timeslot 2
   phys_chan_config TCH/H
  timeslot 3
   phys_chan_config TCH/H
  timeslot 4
   phys_chan_config TCH/H
  timeslot 5
   phys_chan_config TCH/H
  timeslot 6
   phys_chan_config TCH/H
  timeslot 7
   phys_chan_config TCH/H
msc
token msc_token_23_42
core-mobile-country-code 901
core-mobile-network-code 70
ip.access rtp-base 8000
timeout-ping 1800
timeout-ping advanced
timeout-pong 60
codec-list hr3
dest 151.80.237.229 5000 184
amr-config 12_2k forbidden
amr-config 10_2k forbidden
amr-config 7_95k forbidden
amr-config 7_40k forbidden
amr-config 6_70k forbidden
amr-config 5_90k allowed
amr-config 5_15k forbidden
amr-config 4_75k forbidden
---

osmo-bsc -c osmo-bsc.cfg

Above config assumes defaults, a full M3UA/SCCP config would look like

---
cs7 instance 1
point-code 0.42.0
asp asp-clnt-msc-0 2905 0 m3ua
as as-clnt-msc-0 m3ua
 asp asp-clnt-msc-0
 routing-key 2 0.42.0
sccp-address bsc_local
 routing-indicator PC
 point-code 0.42.0
sccp-address msc_remote
 routing-indicator PC
 point-code 0.0.1
msc 0
bsc-addr bsc_local
msc-addr msc_remote
---


Upon startup, I see e.g. osmo-bsc logs like

20170918133916790 DLINP <0002> ../../../src/libosmo-netif/src/stream.c:558 accept()ed new link from 127.0.0.1 to port 2905
20170918133916790 DLSS7 <000c> ../../../src/libosmo-sccp/src/osmo_ss7.c:1606 (r=127.0.0.1:50020<->l=127.0.0.1:2905): New m3ua connection accepted
20170918133916790 DLSS7 <000c> ../../../src/libosmo-sccp/src/osmo_ss7.c:1642 (r=127.0.0.1:50020<->l=127.0.0.1:2905): created dynamicASP asp-dyn-1


Looking through this, I see various bits that still need polishing, but the
current osmo-bsc,stp,msc setup should work as it is.

I hope you will get a working setup going with this information, and once the
osmo-msc debian builds again.

Thanks for reporting!

~N


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

From hwelte at sysmocom.de  Tue Sep 19 09:46:19 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Tue, 19 Sep 2017 17:46:19 +0800
Subject: Using the TTCN-3 test suites in osmo-ttcn3-hacks.git
Message-ID: <20170919094619.ruk25tqdhbhupbc2@nataraja>

Hi all,

I've been creating some test suites for various different interfaces
and Osmocom elements in osmo-ttcn3-hacks.git.

In case you want to use and/or extend them, here is some introduction
in how to build them and how to use them.

I've updated
https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Notes
with some information on how I build + execute + view the logs, maybe
this is useful to you.  Let me know if you have any questions.

For sure this could be more automatized (like cloning the dependencies
or even using them as git-submodule), but so far I'm investing every
minute I have in increasing test coverage, rather than convenience
features.

Regards,
	Harald

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


From nhofmeyr at sysmocom.de  Wed Sep 20 14:06:16 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 20 Sep 2017 16:06:16 +0200
Subject: HEADS UP: stricter VTY, possible config fallout
Message-ID: <20170920140616.GA3835@my.box>

Hi all,

we have recently merged a profound change to the inner workings of the VTY
configuration. We've hit some fallout due to that, hence I would like to let
you know that you might hit the same.

The VTY parsing of config files is now strict about indenting.
A child node *must* be indented below the parent node,
and indenting must be consistent.

For more details on the reason why and a definition of 'consistent', see the
commit log of
https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a0495c57552f0ad


So, if you are in the near future faced with config files being rejected that
worked perfectly before, it is most probably because your indenting was wrong
all the time, and only now did we start checking it.

If the cause is hard to figure out, a good aid is the telnet VTY, where you may
either 'show running-config' or traverse the nodes manually to query which
command exists on which level. If your current config is broken, you may be
able to start the program with an empty or stripped down config file to make
its telnet available.


The above is about reading config files, but we have also dropped the implicit
'exit' to parent level on the telnet VTY console. This caused fallout where
nodes by plain omission lack the 'exit' command: one is unable to leave such a
node once it is entered. That is a fault in the program's VTY setup that was
not found before, because the VTY would often just find the parent node's exit
command instead. I have a patch to avoid all of these everywhere, by
installing the exit and end commands automatically for every VTY node that gets
created; it is not merged yet:  https://gerrit.osmocom.org/3998


------ Config Fallout Example ------

For example, we hit a breakage with this osmo-bts-trx.cfg:

phy 0
 instance 0
 osmotrx rx-gain 25
 osmotrx tx-attenuation oml
 osmotrx ip local 10.23.42.1
 osmotrx ip remote 10.23.42.2

Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does
not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance
0'.  The first fix looked like this:

phy 0
 instance 0
  osmotrx rx-gain 25
  osmotrx tx-attenuation oml
  osmotrx ip local 10.23.42.1
  osmotrx ip remote 10.23.42.2

But alas, this time it said the command 'osmotrx ip local' does not exist.  I
suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a
direct child of the 'phy 0' level. Before, the VTY would implicitly step out of
a child level if it found a matching command one parent above. That is
confusing in other situations (see above commit log), hence we now require
indenting to clarify the structure. This is the correct one:

phy 0
 instance 0
  osmotrx rx-gain 25
  osmotrx tx-attenuation oml
 osmotrx ip local 10.23.42.1
 osmotrx ip remote 10.23.42.2

Or rephrased:

phy 0
 osmotrx ip local 10.23.42.1
 osmotrx ip remote 10.23.42.2
 instance 0
  osmotrx rx-gain 25
  osmotrx tx-attenuation oml


To query the structure via telnet, I did:

    $ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg

    $ telnet localhost 4241
    OsmoBTS> enable 
    OsmoBTS# configure terminal 
    OsmoBTS(config)# phy 0
    OsmoBTS(phy)# list
      [...]
      osmotrx ip HOST
      osmotrx ip (local|remote) A.B.C.D
      [...]
    OsmoBTS(phy)# inst
    OsmoBTS(phy)# instance 0
    OsmoBTS(phy-inst)# list
      [...]
      osmotrx rx-gain <0-50>
      osmotrx tx-attenuation <0-50>
      osmotrx tx-attenuation oml
      [...]


------ No Exit Example ------

The same osmo-trx VTY nodes also show the exit failure:

    $ telnet localhost 4241
    OsmoBTS> enable 
    OsmoBTS# configure terminal 
    OsmoBTS(config)# phy 0
    OsmoBTS(phy)# exit
    % Unknown command.
    OsmoBTS(phy)# instance 0
    OsmoBTS(phy-inst)# exit
    % Unknown command.

On the phy level, we would previously find the parent's 'exit' command, but in
the 'instance' level, 'exit' has never been available. Above patch should fix
all of these.

~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/20170920/ab25ba2a/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Sep 20 14:48:43 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 20 Sep 2017 16:48:43 +0200
Subject: OSMO-BSC integration to other MSC
In-Reply-To: <FECB6503-49B9-4EF6-BC6E-0D065F9E80A3@gmail.com>
References: <FECB6503-49B9-4EF6-BC6E-0D065F9E80A3@gmail.com>
Message-ID: <20170920144843.GC3835@my.box>

On Tue, Sep 19, 2017 at 01:18:44PM +0800, Bob Skie wrote:
> If we are going to integrate OSMO-BSC to another MSC, for example, a Huawei MSC, what components do we need?
> 
> Is their a link that can help us do this task?

We have the "old" osmo-bsc talking SCCPlite to the MSC, and the "new" osmo-bsc
talking SCCP/M3UA (not yet documented well). You should be able to connect them
by following the manuals and example config files.
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Manuals
https://git.osmocom.org/osmo-bsc/tree/doc/examples/osmo-bsc (new)
https://git.osmocom.org/openbsc/tree/openbsc/doc/examples/osmo-bsc (old)

However, integrating to an MSC of so far untested vendor is likely to be
non-trivial. If you require assistance with that, may I suggest to purchase
support from one of the companies proficient in Osmocom software. Doing so is
appreciated, as it will help fund the Osmocom community -- for example, this
mail you are receiving is funded by support contracts purchased from
sysmocom.de.

Thanks!
~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/20170920/0edbe30a/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Sep 20 17:45:14 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 20 Sep 2017 19:45:14 +0200
Subject: osmo-bsc integration to osmo-msc
In-Reply-To: <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>
References: <DCBEB337-A95F-4BBA-8B07-2A2C631996F4@entropysolution.com>
 <20170917132101.5bu3xwg6utqrwbov@nataraja>
 <52BC5242-4FC1-4297-8CC8-24CEAC53A83F@entropysolution.com>
 <20170917140600.tsb2eem3tmn7xh7z@nataraja>
 <23D1F091-A925-40CD-99A2-FB4234D21CF2@entropysolution.com>
 <20170918115049.GA1618@my.box>
 <81272B5E-1641-41DD-9C4D-C3533CB4B215@entropysolution.com>
Message-ID: <20170920174514.GE3835@my.box>

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

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

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

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

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

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

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

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          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/20170920/9b9421b5/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Sep 20 20:07:55 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 20 Sep 2017 22:07:55 +0200
Subject: API versions vs. release versions
Message-ID: <20170920200755.GF3835@my.box>

It seems there are a lot more versionings around than I thought...

I am currently deciding on how we want to handle libtool API versions.
These are strings of the form
  current:revision_of_current:compat_age

MGCP_LIBVERSION=5:23:4
means that
 - We are in API version 5.
 - This is the 23rd "small internal" modification of 5.
 - We are backwards compatible to 4 previous API versions (1 thru 5).

This is not at all related to release versions of the major.minor.patch form.
For example, each small tweak of the code will bump the middle
'revision_of_current' number, whether it's a minor or patch release bump.

Now I had the plan to actually coincide the major release version with the API
current version. When we are in release 1.0.1 thru 1.23.42 and so forth, keep
the library API current version at 1. Once we do a major version bump to 2.0.0,
we can go on to API current version 2. Coinciding seems to make sense because
we anyway don't want to make API breaking changes unless we bump the major
release number.

BTW the API 'current' version number also appears in the debian package names
like libosmo-mgcp2.deb and the installed library files, like
libosmo-mgcp.so.2...

Keeping the API current the same as release major makes sense to me, but only
up to this point: when we add a new side feature to a library.

When all of the library stays the same and is backwards compatible, and all we
do is add a new function to it, someone linking against it may want to make
sure that this new function is included in the installed version.  So even if
we don't bump a major release, don't break API and so forth, we may still want
to increase the API-current version and bump the names of the debian packages
as well as installed .so files.

Why? Because if we had libosmo-mgcp1 and added function mgcp_frobnicate(), and
we want to use mgcp_frobnicate() in osmo-msc.deb, we want to depend on a
libosmo-mgcp that has it added, i.e. we bump to libosmo-mgcp2.deb and depend on
that from osmo-msc.deb. All the while libosmo-mgcp's version tag still remains
at 1.0.23, only the API version changed.

This would be the libtool-intended way, and we'd see a lot of debian package
names' numbers bumping, not at all related to our major-release, whenever we
add any new function to our API.

Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be
libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me?

According to libtool, coinciding the API version with the release version is
abuse. OTOH it's what I actually expected for most of my life... :/

Will we have the discipline to bump API current for each addition?
And bump each depending projects' debian depends-clauses?

What do you guys think about this?

See https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

Thanks!

~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/20170920/c2bb6300/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Sep 20 22:48:28 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Sep 2017 00:48:28 +0200
Subject: request for gerrit votes to fix debian packages
Message-ID: <20170920224828.GA27637@my.box>

To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
patches in osmo-mgw to be merged:

https://gerrit.osmocom.org/3999
https://gerrit.osmocom.org/4000
https://gerrit.osmocom.org/4001
https://gerrit.osmocom.org/4002
https://gerrit.osmocom.org/4003
https://gerrit.osmocom.org/4005

(topic 'new_mgw' less 4006 and 4007)

If review takes too long I am tempted to just merge it ahead to fix the state
of osmo-msc.deb in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly

If I do, it means that I would like to fix and improve those patches later, not
that I want to smuggle them past review. I just want to finally get the debian
builds working and off my mind again.

The osmo-msc currently fails because it needs a header file not included in
libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
which are of course not included in the libosmo-mgcp-client deb. I want them to
be separated completely to save us this kind of cumbersomeness in the future.
Only one of the above commits unties libosmo-mgcp-client from the other libs,
but small bits here and there make the change depend on the others in that
bunch. I could re-arrange, but that would take time. I'd rather just keep them
in that order, we want them merged anyway.

The large ones in the middle are dexter's work on the next generation MGW that
happened on a branch, being placed beside the legacy code. This way we can move
from legacy to new code in osmo-msc and osmo-bsc independently.

~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/20170921/0e7f380f/attachment.bin>

From laforge at gnumonks.org  Thu Sep 21 04:49:13 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 21 Sep 2017 12:49:13 +0800
Subject: request for gerrit votes to fix debian packages
In-Reply-To: <20170920224828.GA27637@my.box>
References: <20170920224828.GA27637@my.box>
Message-ID: <20170921044913.hipnck6z2ja5bv5r@nataraja>

Hi Neels,

On Thu, Sep 21, 2017 at 12:48:28AM +0200, Neels Hofmeyr wrote:
> To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
> patches in osmo-mgw to be merged:
> 
> [...]
> https://gerrit.osmocom.org/4003

I'm surprised about this.  Why would an entirely new osmo-mgw
implementation be needed to build debian packages, if that
implementation is not yet reviewed and not yet used from either osmo-bsc
or osmo-msc master?

> If review takes too long I am tempted to just merge it ahead to fix the state
> of osmo-msc.deb in
> https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly

Please don't.  I've just spent a long time and have lots of review
comments on 4003 alone.  There's nothing wrong at all with the work
being done so far, to the contrary.  I just think it is not ready yet.
In fact, it has never gone through any review, and your commit above has
been the first time this went into gerrit at all.

> If I do, it means that I would like to fix and improve those patches later, not
> that I want to smuggle them past review. I just want to finally get the debian
> builds working and off my mind again.

I don't think debian package builds should depend on significant new
code that is not in master yet.

> The osmo-msc currently fails because it needs a header file not included in
> libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
> which are of course not included in the libosmo-mgcp-client deb. I want them to
> be separated completely to save us this kind of cumbersomeness in the future.

I'm not following.

> Only one of the above commits unties libosmo-mgcp-client from the other libs,
> but small bits here and there make the change depend on the others in that
> bunch. I could re-arrange, but that would take time. I'd rather just keep them
> in that order, we want them merged anyway.

The design/architecture of the new osmo-mgw needs to be done right
before we merge it.  Related code has not been subject to review so far,
and I think it will still take quite a bit.  There's no point in rushing
this now, then make osmo-{bsc,msc} use that and then do another
iteration of changes which will very likely affeect the protocol and
thus interoperability with osmo-{bsc,msc}.

I'm all in favor of efficiency and not spending time on re-arranging
patches.  The question to me is rather why were the untangling patches
developed based on a non-master branch of very large ongoing development
work, rather than on master?  AFAICT, this is the reason we now need to
spend extra time to re-order the patches.

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


From laforge at gnumonks.org  Thu Sep 21 05:20:47 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 21 Sep 2017 13:20:47 +0800
Subject: API versions vs. release versions
In-Reply-To: <20170920200755.GF3835@my.box>
References: <20170920200755.GF3835@my.box>
Message-ID: <20170921052047.ulw2ayfhivusgziw@nataraja>

Hi Neels,

On Wed, Sep 20, 2017 at 10:07:55PM +0200, Neels Hofmeyr wrote:
> It seems there are a lot more versionings around than I thought...

Really?  There's basially just the LIBVERSION related to a librrary API
(or actually ABI), and the package version.  And those two have no
relation.

> MGCP_LIBVERSION=5:23:4
> means that
>  - We are in API version 5.
>  - This is the 23rd "small internal" modification of 5.
>  - We are backwards compatible to 4 previous API versions (1 thru 5).
> 
> This is not at all related to release versions of the major.minor.patch form.

correct.

> For example, each small tweak of the code will bump the middle
> 'revision_of_current' number, whether it's a minor or patch release bump.

ack.

> Now I had the plan to actually coincide the major release version with the API
> current version. When we are in release 1.0.1 thru 1.23.42 and so forth, keep
> the library API current version at 1. Once we do a major version bump to 2.0.0,
> we can go on to API current version 2. Coinciding seems to make sense because
> we anyway don't want to make API breaking changes unless we bump the major
> release number.

Without giving it too much thought: Intuitively it seems strange to tie
the two to each other?

> BTW the API 'current' version number also appears in the debian package names
> like libosmo-mgcp2.deb and the installed library files, like
> libosmo-mgcp.so.2...

yes, that's how you make sure you can install two different 'current'
versions of a given library concurrently, in case you have some programs
requiring an old version (.so.1) and some a new (.so.2) installed
concurrently.

> This would be the libtool-intended way, and we'd see a lot of debian package
> names' numbers bumping, not at all related to our major-release, whenever we
> add any new function to our API.

ack.

> Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be
> libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me?

I think that's a common misunderstanding, and one that people have to
get over with, we cannot fix common misconceptions about underlying
technology in use in Osmocom.

Just look at any random Debian system:

ii  libavutil52:amd64                                           10:2.3.3-dmo3                          amd64        FFmpeg avutil library - runtime files
ii  libavutil54:amd64                                           10:2.4.1-dmo1                          amd64        FFmpeg avutil library - runtime files
ii  libavutil55:amd64                                           7:3.3.3-4

You can see quite clearly that it's completely normal to have
commonly-used packages that don't follow the "abuse" but have source
code release versions completely independent of library ABI versions.

> According to libtool, coinciding the API version with the release version is
> abuse. OTOH it's what I actually expected for most of my life... :/

I think all of us learn new things all the time, so no worries about
that :)

> Will we have the discipline to bump API current for each addition?

At least this is the plan / expectation.

> And bump each depending projects' debian depends-clauses?

The question to me is: Can we automatize/script this in some way, at
least partially so that it's easy to avoid making mistakes.

I think the most difficult question is on th "application/library-user"
side, i.e. when you use a given function from a particular library: How
do you know in which API/ABI version that given symbol was added?

Alternatively, we could of course simply have a script that *always*
bumps the 'depends' of all our applications every time we bump the API
version on the library.  Not elegant, but would ensure there would never
be any incompatibilities :/

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


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

Hi Neels,

Thank you for the info shared.

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

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

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

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

Thank you.

Best Regard,

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




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

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

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

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

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

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

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

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

~N

--
- Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte

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

From menezer at gmail.com  Thu Sep 21 06:56:29 2017
From: menezer at gmail.com (Bob Skie)
Date: Thu, 21 Sep 2017 14:56:29 +0800
Subject: OSMO-BSC integration to other MSC
In-Reply-To: <20170920144843.GC3835@my.box>
References: <FECB6503-49B9-4EF6-BC6E-0D065F9E80A3@gmail.com>
 <20170920144843.GC3835@my.box>
Message-ID: <9728393C-56C8-427C-9B2E-19107388DF5B@gmail.com>

Hi Neels,

Noted on this and thank you for the links you have shared.

We?ll be checking on those.

For the support, my colleague Vien already sent an email to sysmocom.de.

Thank you,

Bob


> On Sep 20, 2017, at 10:48 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> On Tue, Sep 19, 2017 at 01:18:44PM +0800, Bob Skie wrote:
>> If we are going to integrate OSMO-BSC to another MSC, for example, a Huawei MSC, what components do we need?
>> 
>> Is their a link that can help us do this task?
> 
> We have the "old" osmo-bsc talking SCCPlite to the MSC, and the "new" osmo-bsc
> talking SCCP/M3UA (not yet documented well). You should be able to connect them
> by following the manuals and example config files.
> https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Manuals
> https://git.osmocom.org/osmo-bsc/tree/doc/examples/osmo-bsc (new)
> https://git.osmocom.org/openbsc/tree/openbsc/doc/examples/osmo-bsc (old)
> 
> However, integrating to an MSC of so far untested vendor is likely to be
> non-trivial. If you require assistance with that, may I suggest to purchase
> support from one of the companies proficient in Osmocom software. Doing so is
> appreciated, as it will help fund the Osmocom community -- for example, this
> mail you are receiving is funded by support contracts purchased from
> sysmocom.de.
> 
> Thanks!
> ~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



From msuraev at sysmocom.de  Thu Sep 21 10:39:11 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 21 Sep 2017 12:39:11 +0200
Subject: Osmo-trx build problem
In-Reply-To: <20170918003832.GB11540@my.box>
References: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
 <20170918003832.GB11540@my.box>
Message-ID: <52795fe0-cff9-c057-c5ab-96ea60932738@sysmocom.de>

On 18.09.2017 02:38, Neels Hofmeyr wrote:
> 'bumpversion' has been discussed elsewhere, with an indication that we may want
> to remove this dependency again. It should anyway just be needed for making a
> release, I'm not sure why this appears during normal build from source.
It's already removed as of 98f6482ec7eb603b17e5a99fb92d28c17fcf61e9 in libosmocore.

Also, https://gerrit.osmocom.org/#/c/3973/ suppress error message. I don't believe it
have anything to do with the build problem but let's wait for complete logs.

-- 
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 pablo at gnumonks.org  Thu Sep 21 11:44:02 2017
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Thu, 21 Sep 2017 13:44:02 +0200
Subject: HEADS UP: stricter VTY, possible config fallout
In-Reply-To: <20170920140616.GA3835@my.box>
References: <20170920140616.GA3835@my.box>
Message-ID: <20170921114402.GA5148@salvia>

Hi Neels,

On Wed, Sep 20, 2017 at 04:06:16PM +0200, Neels Hofmeyr wrote:
> Hi all,
> 
> we have recently merged a profound change to the inner workings of the VTY
> configuration. We've hit some fallout due to that, hence I would like to let
> you know that you might hit the same.
> 
> The VTY parsing of config files is now strict about indenting.
> A child node *must* be indented below the parent node,
> and indenting must be consistent.
> 
> For more details on the reason why and a definition of 'consistent', see the
> commit log of
> https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a0495c57552f0ad

I understand there are a good reasons for this and that a lot of
experimentation is going on to consolidate the project.

But it would be good to keep in the horizon to have a more stricter
policy on breaking backward compatibility, even if there are good
reason to fix up inconsistent things, or fix in new software, eg.
osmo-bsc while keeping the current behaviour around in the legacy
openbsc.git tree.

I don't want to create any long debate on this, just an observation.

Thanks!


From nhofmeyr at sysmocom.de  Thu Sep 21 13:09:23 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Sep 2017 15:09:23 +0200
Subject: Osmo-trx build problem
In-Reply-To: <52795fe0-cff9-c057-c5ab-96ea60932738@sysmocom.de>
References: <CAL4AEb9GSZMC46tGHeT6pcEoU9gHCCan92SBCnL6C=YA830=zw@mail.gmail.com>
 <20170918003832.GB11540@my.box>
 <52795fe0-cff9-c057-c5ab-96ea60932738@sysmocom.de>
Message-ID: <20170921130923.GB1801@my.box>

On Thu, Sep 21, 2017 at 12:39:11PM +0200, Max wrote:
> On 18.09.2017 02:38, Neels Hofmeyr wrote:
> > 'bumpversion' has been discussed elsewhere, with an indication that we may want
> > to remove this dependency again. It should anyway just be needed for making a
> > release, I'm not sure why this appears during normal build from source.
> It's already removed as of 98f6482ec7eb603b17e5a99fb92d28c17fcf61e9 in libosmocore.

This is not accurate. You have removed the debian packaging dependency on
bumpversion, but you are still using it from libosmocore, which IMHO is a
questionable approach. The idea was to not use bumpversion *at all*.

Could you explain briefly what the input and output of the bumpversion step
are? Like, does it always bump the patch version, never the minor or major
versions?

I would expect version bumping to be a human choice, i.e. I decide to tag a new
release with patch, minor or major version bumped, then 'make release' takes
that tag's version as a basis?

If tagging should happen automatically, we could ask the user to enter the new
version at a prompt or by makefile parameter.

> Also, https://gerrit.osmocom.org/#/c/3973/ suppress error message.

Nice, added review.

> I don't believe it have anything to do with the build problem

Indeed, probably not.

~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/20170921/dc43333f/attachment.bin>

From laforge at gnumonks.org  Thu Sep 21 13:48:20 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 21 Sep 2017 21:48:20 +0800
Subject: HEADS UP: stricter VTY, possible config fallout
In-Reply-To: <20170921114402.GA5148@salvia>
References: <20170920140616.GA3835@my.box>
 <20170921114402.GA5148@salvia>
Message-ID: <20170921134820.nfog53jqmrxb3xwu@nataraja>

Hi Pablo,

On Thu, Sep 21, 2017 at 01:44:02PM +0200, Pablo Neira Ayuso wrote:
> I understand there are a good reasons for this and that a lot of
> experimentation is going on to consolidate the project.
> 
> But it would be good to keep in the horizon to have a more stricter
> policy on breaking backward compatibility, even if there are good
> reason to fix up inconsistent things, or fix in new software, eg.
> osmo-bsc while keeping the current behaviour around in the legacy
> openbsc.git tree.

That's of course hard if the given code is part of libosmocore, which is
used by all osmocom programs.  However, you can (and will be able to)
build osmo-nitb still against older versions of libosmocore to retain
the old behavior.

One could of course introduce a runtime swithc or (beware) a
compile-time switch.  But then, you also have to maintain two sets of
documentation, test both behaviours from the VTY tests, etc. - and the
effort quickly explodes.

> I don't want to create any long debate on this, just an observation.

Your thoughts are much appreciated, and I know that this is a
contentious issue.

The problem is that with the constant scarcity of resources and the
limited funding (and even more so, code contributions) to cover an
extremely large problem space - basically the entire 2G/3G cellular
network architecture, covering all network elements and all layers of
each of the protocol stacks on its interfaces.  Supporting too many
different 'ways of doing things' is going make the matrix explode beyond
what a small team can manage to develop and maintain.  We have to invest
our time wisely.

So, sometimes in earlier days there were now seemingly stupid choices
that we need to change later on.  Or we inherited code with properties
that were not fully understood (like the VTY code from zebra/quagga,
with its "implicitly try commands of the parent node" feature that
caused fall-out now and had to be fixed).

Those kind of changes are not introduced lightly, and only when we see
no real alternative.  What we could and probably should do better is to
properly document this, e.g. in form of a manually written changelog
that gets published at the time we tag a new version of a given project,
That changlog update should be part of the patch that introduces some
compatibility related code change. But if ti is missed, that changelog
update could also come from another developer or user who finds out and
who wants to ensure nobody else falls into the same trap.

The other thing we can possibly do is some scripts that can aid in the
conversion, like a "fix the indenting of my config file" script that you
can run once during a related upgrade.

At some point we intend to have formal "Osmocom releases", which would
then receive some amount of maintenance and bugfix backporting.
However, once again this consumes considerable resources.  Putting all
this on sysmocom shoulders is unlikely to work.  We will need some
people with significant interest in that to step up and say "yes, I'll
maintain Release X" similar to e.g. a given -stable maintainer of the
kernel.

We've tried to bundle a lot of the large changes with the NITB-split to
make sure there's going to be one time when people do that migration
where all even technically unrelated changes happen at once.  That's for
example the OpenGGSN->OsmoGGSN transition, whih has nothing to do with
the NITB, but we thought it's a good idea to do that at the same time so
people migrating from NITB to BSC+MSC+HLR will not have to do one change
per month but all of them together.

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


From nhofmeyr at sysmocom.de  Thu Sep 21 16:44:23 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Sep 2017 18:44:23 +0200
Subject: HEADS UP: stricter VTY, possible config fallout
In-Reply-To: <20170921114402.GA5148@salvia>
References: <20170920140616.GA3835@my.box>
 <20170921114402.GA5148@salvia>
Message-ID: <20170921164423.GD1801@my.box>

On Thu, Sep 21, 2017 at 01:44:02PM +0200, Pablo Neira Ayuso wrote:
> But it would be good to keep in the horizon to have a more stricter
> policy on breaking backward compatibility, even if there are good
> reason to fix up inconsistent things, or fix in new software, eg.
> osmo-bsc while keeping the current behaviour around in the legacy
> openbsc.git tree.

Yes, I mentioned this idea in the patch submission: to be able to pass a flag
to the VTY to enable or disable the new indentation bound behavior. The patch
was accepted without it, but I would still favor such an implementation. It
would be logical if I did this, but I have a multitude of tasks for the current
change to the new repositories. Not sure if sysmocom would fund that, given
that the focus is on the new repositories.

As a workaround, it is always possible to use a libosmocore without the VTY
patches:

git clone git://git.osmocom.org/libosmocore
cd libosmocore
git revert 430636328c2fbd9fffc0eac5114462c200b7f2cb 4a31ffa2f0097d96201f80305a0495c57552f0ad

Another workaround would be to not update the OsmoNITB installations on running
systems. After all, our intention is to not spend time on new implementations
for the old openbsc repository.

The reason why we are doing these things now is that it is a good thing to
change everything at once, minimizing the effort for users to change over.

Nevertheless, there are various other features that the old OsmoNITB offered,
which we either need to re-implement in the new split way, or which users need
to farewell:
- accept-all policy, entering phone numbers in the HLR automatically for
  arbitrary SIM cards.
- keeping an IMEI[SV] database beyond volatile in-ram subscriber storage.
- introspection of BTS data on the MSC level, i.e. correlate subscribers with
  actual lchans on a specific BTS.
and probably some more.

Do not hesitate to ask about these, be they long discussions or not.  The most
important aspect after all is to keep the community thriving and affirmative
towards Osmocom developments.

~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/20170921/485cb8c9/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Sep 21 17:01:38 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Sep 2017 19:01:38 +0200
Subject: API versions vs. release versions
In-Reply-To: <20170921052047.ulw2ayfhivusgziw@nataraja>
References: <20170920200755.GF3835@my.box>
 <20170921052047.ulw2ayfhivusgziw@nataraja>
Message-ID: <20170921170138.GE1801@my.box>

On Thu, Sep 21, 2017 at 01:20:47PM +0800, Harald Welte wrote:
> > It seems there are a lot more versionings around than I thought...
> 
> Really?  There's basially just the LIBVERSION related to a librrary API
> (or actually ABI), and the package version.  And those two have no
> relation.

(And then we also have the feeds of built packages. I hope we'll put the first
one in place on December 1st, Osmocom CellNet 17.12, to start off the planned
schedule of a new feed every three months.)

> > Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be
> > libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me?
> 
> I think that's a common misunderstanding, and one that people have to
> get over with, we cannot fix common misconceptions about underlying
> technology in use in Osmocom.

Ok, thanks for the clarification!

> I think the most difficult question is on th "application/library-user"
> side, i.e. when you use a given function from a particular library: How
> do you know in which API/ABI version that given symbol was added?

The only way to ensure we don't make mistakes there is to have an automated way
that tries to build/link programs against each depending libraries' both
beginning and end of the API version it claims to be compatible with.

I remember we mentioned something like this earlier in a release mail thread.

Max asked me to transfer our comments and conclusions to the 'Making a Release'
wiki page, and indeed I have gathered a lot of knowledge on it now. I would
anyway nitpick around on anything someone else wrote :P

First though I am focusing on remaining openbsc.git split tasks, like the
manuals and debian packaging. There's also still loads of dead code to be
pruned.

BTW, I feel a bit overloaded at the moment, my attention often drawn away from
those urgent topics. I'm also a bit fed up with releng, jenkins, mails and docs
and would enjoy some good old hacking for a change :)

Well, anyway, getting on with it...
It should be over and mostly done *some* day.

~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/20170921/8d399a43/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Sep 21 17:17:59 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Sep 2017 19:17:59 +0200
Subject: request for gerrit votes to fix debian packages
In-Reply-To: <20170921044913.hipnck6z2ja5bv5r@nataraja>
References: <20170920224828.GA27637@my.box>
 <20170921044913.hipnck6z2ja5bv5r@nataraja>
Message-ID: <20170921171759.GF1801@my.box>

On Thu, Sep 21, 2017 at 12:49:13PM +0800, Harald Welte wrote:
> > https://gerrit.osmocom.org/4003
> 
> I'm surprised about this.  Why would an entirely new osmo-mgw
> implementation be needed to build debian packages, if that
> implementation is not yet reviewed and not yet used from either osmo-bsc
> or osmo-msc master?

We can strip the addition of debian packages for later, if that's better.

> > If review takes too long I am tempted to just merge it ahead to fix the state
> > of osmo-msc.deb in
> > https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
> 
> Please don't.  I've just spent a long time and have lots of review

ack

> In fact, it has never gone through any review, and your commit above has
> been the first time this went into gerrit at all.

It's hopefully the last of the series of code bomb developments we faced this
year. I'm looking forward to normal gerrit patch submissions from then on.

> > The osmo-msc currently fails because it needs a header file not included in
> > libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
> > which are of course not included in the libosmo-mgcp-client deb. I want them to
> > be separated completely to save us this kind of cumbersomeness in the future.
> 
> I'm not following.

The split off libosmo-mgcp-client still used headers from libosmo-legacy-mgcp.
After a 'make install', all of them are present, but from just a -client deb
package, they aren't.

I prefer to avoid this kind of interdependency, reminding me of
gsm_data_shared.h.

There still is one header file of shared code, but I want each library to have
its own copy of it.  To avoid code dup, I want that copy to be made at
'make'-time -- ok because it's within the same git repository.

That is the main reason why I was waiting for the new version of
libosmo-mgcp-client to fix the osmo-msc deb package. This shared header needs
to be part of the deb.

After reading this, I will fix the osmo-msc.deb beforehand. I will copy the
shared header over, and put the sharing thereof in place after the new mgw has
been merged. We can then also discuss that part later.


> why were the untangling patches developed based on a non-master branch of
> very large ongoing development work, rather than on master?

I assumed we would go through it more quickly, maybe a misconception.

~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/20170921/5c8843b1/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Sep 22 00:23:54 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 22 Sep 2017 02:23:54 +0200
Subject: request for gerrit votes to fix debian packages
In-Reply-To: <20170921044913.hipnck6z2ja5bv5r@nataraja>
References: <20170920224828.GA27637@my.box>
 <20170921044913.hipnck6z2ja5bv5r@nataraja>
Message-ID: <20170922002354.GB12471@my.box>

On Thu, Sep 21, 2017 at 12:49:13PM +0800, Harald Welte wrote:
> I'm all in favor of efficiency and not spending time on re-arranging
> patches.

I have now re-arranged patches and kindly request review of only
https://gerrit.osmocom.org/4010
which is my favorite way of fixing the libosmo-mgcp-client-dev.deb

The result should be that osmo-msc.deb will finally build successfully again,
because libosmo-mgcp-client-dev is fixed to not need headers it doesn't
install.

4010 will cause minor conflicts with the large 4003 in review, which I have
solved, but am keeping on branch neels/new_mgw and not pushing to gerrit yet,
to wait for dexter and not get in his way there. Once his next patch set is
ready (he should for convenience stay on the current master and not rebase onto
4010), I will consolidate with 4010 and rebase+solve 4003 so that all matches
up again.

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/20170922/03c00494/attachment.bin>

From anindya.s at toshniwalcontrols.com  Fri Sep 22 07:43:55 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Fri, 22 Sep 2017 13:13:55 +0530
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <CAAj2SE0f+qV-1q0yKHTPFWzT-f8uZN7-HjyxWde7q89=Q3U-vg@mail.gmail.com>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
 <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
 <20170914152055.GC3999@my.box>
 <CAAj2SE0f+qV-1q0yKHTPFWzT-f8uZN7-HjyxWde7q89=Q3U-vg@mail.gmail.com>
Message-ID: <CAAj2SE2=4uWEfxoz=_12u0mcfUP923h8-xm=WXshVVVYj5wzQA@mail.gmail.com>

Hello everyone,

Nothing has solved, I have removed all the source files and started
fresh... there are osmo-bsc deb in software center and I have installed
them but they give this following error... Can anyone tell me how to solve
it ?

lab at openair4G:/usr/share/doc/osmocom-bsc$ osmo-bsc
<0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
Bootstrapping the network failed. exiting.
full talloc report on 'sccp' (total      1 bytes in   1 blocks)

Thanks

Anindya


On Fri, Sep 15, 2017 at 5:06 PM, Anindya Sankar Roy <
anindya.s at toshniwalcontrols.com> wrote:

> Hello,
>
>  No , I have installed all the packages but still gives the same error.. I
> think maybe upgrading to 16.04  might help... I will retry and repost if
> getting it to 16.04 solves the problem.
>
> Thanks
> Anindya
>
> On Thu, Sep 14, 2017 at 8:50 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de>
> wrote:
>
>> On Thu, Sep 14, 2017 at 12:25:41PM +0530, Anindya Sankar Roy wrote:
>> > Hello,
>> >
>> >  I am getting this error, can anyone tell me what I need to do from
>> > studying the error message
>> >
>> > lab at openair4G:~/dev/open-gsm/osmo-bsc$ autoreconf -fi
>> > configure.ac:9: installing './install-sh'
>> > configure.ac:9: installing './missing'
>> > src/ipaccess/Makefile.am: installing './depcomp'
>> > src/libbsc/Makefile.am:16: error: library used but 'RANLIB' is undefined
>> > src/libbsc/Makefile.am:16:   The usual way to define 'RANLIB' is to add
>> > 'AC_PROG_RANLIB'
>>
>> 'ranlib' is a tool coming from binutils. It should have come with the
>> build-essential package. It seems the ubuntu dependencies list is
>> incomplete,
>> please take the debian one from
>> https://osmocom.org/projects/cellular-infrastructure/wiki/Bu
>> ild_from_Source:
>>
>>   apt-get install build-essential gcc g++ make automake autoconf libtool
>> pkg-config libtalloc-dev libpcsclite-dev libortp-dev libsctp-dev libssl-dev
>> libdbi-dev libdbd-sqlite3 libsqlite3-dev libpcap-dev libc-ares-dev sqlite3
>>
>> Would be great if you could confirm that this list works, then we can
>> update
>> the wiki.
>>
>> Otherwise, ubuntu 14 is quite old by now. You may want to use a newer
>> one. We
>> build our binary packes for 16.04, 16.10 and 17.04, as well as Debian 8
>> and 9.
>> https://build.opensuse.org/project/show/network:osmocom:nightly
>>
>> ~N
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170922/4219bb39/attachment.htm>

From keith at rhizomatica.org  Fri Sep 22 08:22:13 2017
From: keith at rhizomatica.org (Keith)
Date: Fri, 22 Sep 2017 08:22:13 +0000
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <CAAj2SE2=4uWEfxoz=_12u0mcfUP923h8-xm=WXshVVVYj5wzQA@mail.gmail.com>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
 <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
 <20170914152055.GC3999@my.box>
 <CAAj2SE0f+qV-1q0yKHTPFWzT-f8uZN7-HjyxWde7q89=Q3U-vg@mail.gmail.com>
 <CAAj2SE2=4uWEfxoz=_12u0mcfUP923h8-xm=WXshVVVYj5wzQA@mail.gmail.com>
Message-ID: <E0B34C94-A7BD-4F32-B340-FB838DE27343@rhizomatica.org>



On 22 September 2017 09:43:55 CEST, Anindya Sankar Roy <anindya.s at toshniwalcontrols.com> wrote:
>Hello everyone,
>
>Nothing has solved, I have removed all the source files and started
>fresh... there are osmo-bsc deb in software center and I have installed
>them but they give this following error... Can anyone tell me how to
>solve
>it ?


Hi Anindya, let me jump in here to try to avoid consuming developer's time.
First, could I suggest to please take some time to browse through and read the wiki again,  Neels kindly sent links to you, there are also other pages of interest to you there.

Also, please read the documentation.
http://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf
(and other files at the same location)

One cannot be expected to setup something as complex as a full gsm stack without reading the manual, right?

>
>lab at openair4G:/usr/share/doc/osmocom-bsc$ osmo-bsc
><0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
>Bootstrapping the network failed. exiting.

So now you are using the packages and have a totally different error.
If one would read the error, it should be clear that the problem is with the openbsc.cfg file, which I imagine doesn't exist.

Again, I would refer you to the manual, the wiki and this mailing list archive. All the answers you need are there. Your question has been asked before.


-- 
Sent from my Android device.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170922/65129705/attachment.htm>

From anindya.s at toshniwalcontrols.com  Fri Sep 22 10:16:12 2017
From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy)
Date: Fri, 22 Sep 2017 15:46:12 +0530
Subject: Building openBSC in Ubuntu 14.04 kernel 3.19
In-Reply-To: <E0B34C94-A7BD-4F32-B340-FB838DE27343@rhizomatica.org>
References: <CAAj2SE29baD3vTWGDoC=xyQ-hFeNnaU2chbB3yP2V00QZQ+MRQ@mail.gmail.com>
 <20170914000942.GD13204@my.box>
 <CAAj2SE0oXcueCostvqz3nzKb4+YFpG374uV5NFZ_fhXVm0TrWg@mail.gmail.com>
 <20170914152055.GC3999@my.box>
 <CAAj2SE0f+qV-1q0yKHTPFWzT-f8uZN7-HjyxWde7q89=Q3U-vg@mail.gmail.com>
 <CAAj2SE2=4uWEfxoz=_12u0mcfUP923h8-xm=WXshVVVYj5wzQA@mail.gmail.com>
 <E0B34C94-A7BD-4F32-B340-FB838DE27343@rhizomatica.org>
Message-ID: <CAAj2SE2cwCkOWMqMsoCJYFyGGdLvivP9Q5-TgJQGHd-n1cep3g@mail.gmail.com>

I guess, I missed some points or misunderstood something.. I got it working
now...

On Fri, Sep 22, 2017 at 1:52 PM, Keith <keith at rhizomatica.org> wrote:

>
>
> On 22 September 2017 09:43:55 CEST, Anindya Sankar Roy <
> anindya.s at toshniwalcontrols.com> wrote:
> >Hello everyone,
> >
> >Nothing has solved, I have removed all the source files and started
> >fresh... there are osmo-bsc deb in software center and I have installed
> >them but they give this following error... Can anyone tell me how to
> >solve
> >it ?
>
>
> Hi Anindya, let me jump in here to try to avoid consuming developer's time.
> First, could I suggest to please take some time to browse through and read
> the wiki again, Neels kindly sent links to you, there are also other pages
> of interest to you there.
>
> Also, please read the documentation.
> http://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf
> (and other files at the same location)
>
> One cannot be expected to setup something as complex as a full gsm stack
> without reading the manual, right?
>
> >
> >lab at openair4G:/usr/share/doc/osmocom-bsc$ osmo-bsc
> ><0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
> >Bootstrapping the network failed. exiting.
>
> So now you are using the packages and have a totally different error.
> If one would read the error, it should be clear that the problem is with
> the openbsc.cfg file, which I imagine doesn't exist.
>
> Again, I would refer you to the manual, the wiki and this mailing list
> archive. All the answers you need are there. Your question has been asked
> before.
>
>
> --
> Sent from my Android device.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170922/be56d87c/attachment.htm>

From msuraev at sysmocom.de  Sat Sep 23 00:11:30 2017
From: msuraev at sysmocom.de (Max)
Date: Sat, 23 Sep 2017 08:11:30 +0800
Subject: "NITB split" and implications for OsmoSGSN
Message-ID: <20170923001130.33l63bgemlzttkgm@nataraja>

Hi.

There's clearly big difference between split BSC/MSC and NITB
(config files, support for SCCP-lite etc) which makes the transition rather lengthy.

What about SGSN and related stuff? It's been transitioned to libvlr at the time of
split as well, but does this transition have any user-visible consequences?

If not than we could transition gradually:
* make SGSN build optional (--enable-gprs?) in openbsc repo
* start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
* test and make sure that it works the same way (both on sysmobts and on debian)
* disable SGSN build by default and announce that patches should be made against new repo
* remove gprs code from openbsc leaving placeholder readme with the link to new repo

All the steps above are unrelated to BSC/MSC items so it could be done independently.

-- 
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 Sep 23 04:19:20 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 23 Sep 2017 12:19:20 +0800
Subject: "NITB split" and implications for OsmoSGSN
In-Reply-To: <20170923001130.33l63bgemlzttkgm@nataraja>
References: <20170923001130.33l63bgemlzttkgm@nataraja>
Message-ID: <20170923041920.corov3zaqxa6udye@nataraja>

On Thu, Sep 21, 2017 at 04:36:51PM +0200, Max wrote:
> Hi.
>
> On a related note. There's clearly big difference between split BSC/MSC and NITB
> (config files, support for SCCP-lite etc) which makes the transition rather lengthy.
>
> What about SGSN and related stuff? It's been transitioned to libvlr at the time of
> split as well, but does this transition have any user-visible consequences?

Slight misunderstanding: no, the SGSN has "always" had GSUP support and is not
actually using libvlr. All we did is upgrade the SGSN to be able to do UMTS
authentication (Milenage). There was a plan to use libvlr in the SGSN as well,
but since the SGSN is now working as it is, we are unlikely to do that.

> If not than we could transition gradually:
> * make SGSN build optional (--enable-gprs?) in openbsc repo

osmo-sgsn is in its own repository now. Makes no sense to add such config
option there.

> * start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)

yes, that is the transition. The BTS and SGSN are notably the most back- and
forward compatible components in this transition, there isn't much difference
except the M3UA/SCCP addition in the SGSN, which again is only needed for IuPS,
i.e. 3G data. IIRC the entire 2G SGSN land is identical between openbsc.git and
osmo-sgsn.git.  The points needed to transition mostly apply to: BSC, STP, MSC,
HLR, MGW.

> * test and make sure that it works the same way (both on sysmobts and on debian)
> * disable SGSN build by default and announce that patches should be made against new repo
> * remove gprs code from openbsc leaving placeholder readme with the link to new repo

The entire openbsc.git repository will cease to be used. We will not remove
parts from it, we will basically lay it to rest as a whole.

~N


From laforge at gnumonks.org  Sat Sep 23 04:23:01 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 23 Sep 2017 12:23:01 +0800
Subject: "NITB split" and implications for OsmoSGSN
In-Reply-To: <20170923041920.corov3zaqxa6udye@nataraja>
References: <20170923001130.33l63bgemlzttkgm@nataraja>
 <20170923041920.corov3zaqxa6udye@nataraja>
Message-ID: <20170923042301.elmqv7yje2y32pfq@nataraja>

Hi Neels,

On Thu, Sep 21, 2017 at 08:04:26PM +0200, Neels Hofmeyr wrote:
> The entire openbsc.git repository will cease to be used. We will not remove
> parts from it, we will basically lay it to rest as a whole.

This is unrealistic, as there are people who will likely want to
continue to use OsmoNITB for at least some time to come.   I'm thinking
of Rhizomatica or Fairwaves, for example.  Or even various of our 'sysmoBTS starter
kit' users until they do a major upgrade to 201705.  There still might
be the occasional important bug fix that needs to be applied to
openbsc.git

My idea would be: In order to avoid anyone to submit patches against the
GPRS components in there, I think it makes sense to remove those parts
and make sure that we have no two [except for 3G support] identical
copies of the SGSN (plus gtphub, plus gb-proxy) code lying around.  This
will help people who are continuing to use OsmoNITB to get the benefits
of newer versions of SGSN & co, without 'accidentially' sticking to old
versions.

For the remaining NITB code , there should be a strict policy of first
applying any change to OsmoBSC or OsmoMSC, and only then optionally
apply it to openbsc.git.

For sure we should still accept at a minimum clear bug fix commits for
the NITB.  If somebody in the community (or a paying sysmocom customer)
wants to maintain even new features going into the NITB, then we should
simply bless one such person as the legacy NITB maintainer.  The
policy remains: New features and fixes must first be applied to BSC/MSC
and only then to NITB.

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  Sat Sep 23 04:20:50 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 23 Sep 2017 12:20:50 +0800
Subject: "NITB split" and implications for OsmoSGSN
In-Reply-To: <20170923001130.33l63bgemlzttkgm@nataraja>
References: <20170923001130.33l63bgemlzttkgm@nataraja>
Message-ID: <20170923042050.qlgb3wsbtbc5ktfc@nataraja>

Hi Max,

On Thu, Sep 21, 2017 at 04:36:51PM +0200, Max wrote:
> There's clearly big difference between split
> BSC/MSC and NITB (config files, support for SCCP-lite etc) which makes
> the transition rather lengthy.

Not necessarily lengthy, but non-trivial, for sure.

> What about SGSN and related stuff? It's been transitioned to libvlr at the time of
> split as well, but does this transition have any user-visible consequences?

I don't think it has been "transitioned to libvlr", has it?

OsmoSGSN has been supporting GSUP for years longer than OsmoMSC, so
there's not really any user-visible change/transition, other than that
of a different repository.  Or am I missing something?

> If not than we could transition gradually:
> * make SGSN build optional (--enable-gprs?) in openbsc repo

I wouldn't go for that incremental step, but got to removing the code
from openbsc.git altogether, like you suggested later in your mail below

> * start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both
> .deb and OE)

I see no reason why not to.

> * disable SGSN build by default and announce that patches should be > made against new repo
> * remove gprs code from openbsc leaving placeholder readme with the link to new repo

I would suggest that we do both at once, as the code (aside from file
moving/renaming and #include fixups) is exactly the same.

> All the steps above are unrelated to BSC/MSC items so it could be done independently.

ACK.

-- 
- 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 Sep 26 04:56:06 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 26 Sep 2017 04:56:06 +0000
Subject: Error in doing apt-get install in Debian 9
Message-ID: <19144312-D516-4ABF-98B6-FAC63AEE94F3@entropysolution.com>

Hi All,

Not sure if we have an issue in our Debian 9 setup but as we tried to install osmo-bsc, below are the errors we received. Tried to access the FTP server and it is accessible. So what we did is downloaded all the .DEB files and install it manually.

We?ll let you know if we experience errors doing the manual installation of .DEB files.

Logs:
# apt-get install osmo-bsc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libosmo-legacy-mgcp0 libosmo-sccp-dev libosmoabis5 libosmocore8 libosmoctrl0 libosmogsm7 libosmonetif3
  libosmovty3 libsctp1 libtalloc2
Suggested packages:
  lksctp-tools
The following NEW packages will be installed:
  libosmo-legacy-mgcp0 libosmo-sccp-dev libosmoabis5 libosmocore8 libosmoctrl0 libosmogsm7 libosmonetif3
  libosmovty3 libsctp1 libtalloc2 osmo-bsc
0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 759 kB/824 kB of archives.
After this operation, 3,350 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Err:1 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmo-sccp-dev 0.7.1.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmo-sccp-dev_0.7.1.20170926_amd64.deb' is forbidden
Err:2 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmocore8 0.9.6.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmocore8_0.9.6.20170926_amd64.deb' is forbidden
Err:3 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmogsm7 0.9.6.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmogsm7_0.9.6.20170926_amd64.deb' is forbidden
Err:4 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmovty3 0.9.6.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmovty3_0.9.6.20170926_amd64.deb' is forbidden
Err:5 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmoabis5 0.4.0.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmoabis5_0.4.0.20170926_amd64.deb' is forbidden
Err:6 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmoctrl0 0.9.6.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmoctrl0_0.9.6.20170926_amd64.deb' is forbidden
Err:7 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmonetif3 0.0.7.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmonetif3_0.0.7.20170926_amd64.deb' is forbidden
Err:8 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ libosmo-legacy-mgcp0 1.0.2.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmo-legacy-mgcp0_1.0.2.20170926_amd64.deb' is forbidden
Err:9 https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0 ./ osmo-bsc 0.1.0.20170926
  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/osmo-bsc_0.1.0.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmo-sccp-dev_0.7.1.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmo-sccp-dev_0.7.1.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmocore8_0.9.6.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmocore8_0.9.6.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmogsm7_0.9.6.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmogsm7_0.9.6.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmovty3_0.9.6.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmovty3_0.9.6.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmoabis5_0.4.0.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmoabis5_0.4.0.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmoctrl0_0.9.6.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmoctrl0_0.9.6.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmonetif3_0.0.7.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmonetif3_0.0.7.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/libosmo-legacy-mgcp0_1.0.2.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/libosmo-legacy-mgcp0_1.0.2.20170926_amd64.deb' is forbidden
E: Failed to fetch https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/osmo-bsc_0.1.0.20170926_amd64.deb  Redirection from https to 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/osmo-bsc_0.1.0.20170926_amd64.deb' is forbidden
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Best Regard,

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




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

From lynxis at fe80.eu  Tue Sep 26 10:29:36 2017
From: lynxis at fe80.eu (Alexander Couzens)
Date: Tue, 26 Sep 2017 12:29:36 +0200
Subject: Error in doing apt-get install in Debian 9
In-Reply-To: <19144312-D516-4ABF-98B6-FAC63AEE94F3@entropysolution.com>
References: <19144312-D516-4ABF-98B6-FAC63AEE94F3@entropysolution.com>
Message-ID: <20170926122936.71b8a54a@lazus.yip>

Hi Ron,

> https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/osmo-bsc_0.1.0.20170926_amd64.deb
> Redirection from https to
> 'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/osmo-bsc_0.1.0.20170926_amd64.deb'
> is forbidden E: Unable to fetch some archives, maybe run apt-get
> update or try with --fix-missing?

TLDR: use http:// instead of https://download.opensuse.. in your
sources.list

apt is telling you, https -> http redirection are ugly. The
reason for this is: You've written https://download.opensuse.org in
your source.list file, but download.opensuse.org tries to redirect you
to an http:// mirror.
Downloading packages from a http:// mirror isn't a big problem, because
the packages are signed by GPG, so the integrety guaranteed.

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170926/16341433/attachment.bin>

From ron.menez at entropysolution.com  Tue Sep 26 10:53:15 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 26 Sep 2017 10:53:15 +0000
Subject: osmo-bts Installation issues
Message-ID: <90ED316D-C375-4CE7-9E11-131EB4807A8E@entropysolution.com>

Hi All,

We installed osmo-bts-trx using Debian 9 OS through nightly package and encountered an error after running it.

As per checking, there is an existing bug in osmo-bts regarding the "osmobts-trx: error while loading shared libraries: libosmotrau.so.1: cannot open shared object file: No such file or directory? error.

https://osmocom.org/issues/2481

So we tried to install it through building it from source.

Upon installation, we encountered an error upon running ./configure. Error message:

checking whether to enable support for sysmoBTS L1/PHY support... no
checking whether to enable support for osmo-trx based L1/PHY support... no
checking whether to enable support for Octasic OCTPHY-2G... no
checking whether to enable NuRAN Wireless Litecell 1.5 hardware support... no
checking for openbsc/gsm_data_shared.h... no
configure: error: openbsc/gsm_data_shared.h can not be found in /root/osmo-bts/../openbsc/openbsc/include

So we tried to rename the gsm_data.h found in ?~/osmo-bts/include/openbsc? folder to gsm_data_shared.h.

The ./configure goes through but has an error upon running "make?.

Is there another way to install osmo-bts?

Best Regard,

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




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

From ron.menez at entropysolution.com  Tue Sep 26 10:41:39 2017
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 26 Sep 2017 10:41:39 +0000
Subject: Error in doing apt-get install in Debian 9
In-Reply-To: <20170926122936.71b8a54a@lazus.yip>
References: <19144312-D516-4ABF-98B6-FAC63AEE94F3@entropysolution.com>
 <20170926122936.71b8a54a@lazus.yip>
Message-ID: <A4870224-2050-41D7-85C6-0E6988B7EA90@entropysolution.com>

Thanks for the info lynxis. We?ll try that as well.

BTW, installing it manually using the .deb file also did the job.

Best Regard,

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




On Sep 26, 2017, at 6:29 PM, Alexander Couzens <lynxis at fe80.eu<mailto:lynxis at fe80.eu>> wrote:

Hi Ron,

https://download.opensuse.org/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/./amd64/osmo-bsc_0.1.0.20170926_amd64.deb
Redirection from https to
'http://ftp.gwdg.de/pub/opensuse/repositories/network:/osmocom:/nitb-split:/nightly/Debian_9.0/amd64/osmo-bsc_0.1.0.20170926_amd64.deb'
is forbidden E: Unable to fetch some archives, maybe run apt-get
update or try with --fix-missing?

TLDR: use http:// instead of https://download.opensuse.. in your
sources.list

apt is telling you, https -> http redirection are ugly. The
reason for this is: You've written https://download.opensuse.org in
your source.list file, but download.opensuse.org<http://download.opensuse.org> tries to redirect you
to an http:// mirror.
Downloading packages from a http:// mirror isn't a big problem, because
the packages are signed by GPG, so the integrety guaranteed.

Best,
lynxis
--
Alexander Couzens

mail: lynxis at fe80.eu<mailto:lynxis at fe80.eu>
jabber: lynxis at fe80.eu<mailto:lynxis at fe80.eu>
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

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

From nhofmeyr at sysmocom.de  Tue Sep 26 14:00:55 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 26 Sep 2017 16:00:55 +0200
Subject: ctrl interface: GET a variable with parameter
Message-ID: <20170926140055.GB17482@ass40.sysmocom.de>

Yesterday I noticed that apparently we are unable to GET a variable with
argument, e.g. in OsmoHLR get the ps-enabled status of a subscriber and
passing the subscriber's IMSI along for the value we'd like to receive.

Experimenting a bit, I found that for GET commands, any tokens sent after
the variable name are ignored, dropped on the floor and cause neither an
error nor are evaluated.

With a tiny patch, we can make passing arguments to GET parameters
optional:

https://gerrit.osmocom.org/4069

But notably, by adding some CTRL parsing tests I found some interesting
behavior...

https://gerrit.osmocom.org/4067
https://gerrit.osmocom.org/4068


In OsmoHLR, such a status request is so far implemented as a SET, since
SET takes an argument and also returns a result. See:
https://gerrit.osmocom.org/4062 (patch obsolete after 4069)

For that particular set of commands in OsmoHLR:

  enable-ps <IMSI>  (WO)
  disable-ps <IMSI> (WO)
  status-ps <IMSI>  (semantically RO, nevertheless a SET, so technically WO)

I thought it would also make sense to just have one variable for the whole
lot, as in

  subscriber-enable-ps <IMSI>,<val> (RW)

so that we reflect that single value with a single CTRL variable. After
all, that's how the CTRL API appears to be intended: GET and SET commands
on the same entity, instead of blowing up each variable by op * value range.

Or even a command to query and change various subscriber values:

  subscriber <IMSI> <variable>[=<val>] [<variable>[=<val>] [...]] (RW)

e.g.

  GET 1 subscriber 123456789087654 msisdn msc_nr imeisv
  reply: subscriber 123456789087654 msisdn=12345 msc_nr=1 imeisv=123456789abcdef

  SET 1 subscriber 123456789087654 msisdn=54321 msc_nr=4 imeisv=fab123434843823
  reply: OK
  or: "Cannot modify msc_nr, nothing changed"
  or: "Unknown subscriber parameter: xyz"

One step further would be to pick an identification trait from imsi, msisdn or imei...

  GET 1 subscriber imsi=123456789087654 msisdn imeisv
  GET 1 subscriber msisdn=12345 imsi imeisv
  GET 1 subscriber imeisv=12345abcdef123 imsi msisdn

(often a new subscriber in communal networks can easily find the phone's IMEI,
where the IMSI is unknown, so queries like this would be useful in general)

Would this be too much of a monster command? Rather:

  GET 1 subscriber-by-imsi 123456789087654 msisdn imeisv
  GET 1 subscriber-by-msisdn 12345 imsi imeisv
  GET 1 subscriber-by-imeisv 12345abcdef123 imsi msisdn

Comments welcome!

~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/20170926/294acae9/attachment.bin>

From msuraev at sysmocom.de  Wed Sep 27 08:34:21 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 27 Sep 2017 10:34:21 +0200
Subject: ctrl interface: GET a variable with parameter
In-Reply-To: <20170926140055.GB17482@ass40.sysmocom.de>
References: <20170926140055.GB17482@ass40.sysmocom.de>
Message-ID: <4efde062-5ae6-0640-5e74-b0a3e47f765b@sysmocom.de>

On 26.09.2017 16:00, Neels Hofmeyr wrote:
> One step further would be to pick an identification trait from imsi, msisdn or imei...
>
>   GET 1 subscriber imsi=123456789087654 msisdn imeisv
>   GET 1 subscriber msisdn=12345 imsi imeisv
>   GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
Can't we just skip parameters which do not have values and simply use

"GET 1 subscriber msisdn=12345"?

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





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

From laforge at gnumonks.org  Wed Sep 27 11:57:43 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 27 Sep 2017 19:57:43 +0800
Subject: randomness of identifiers
Message-ID: <20170927115743.qkd52rwhf6xtwmuu@nataraja>

Dear all,

Max has been pushing https://gerrit.osmocom.org/#/c/1526 for quite some
time, but there was still no conclusion in its review.

I guess after more than 8 months in limbo, it's about time we decide how
to move ahead with this.

In general, we *want* secure/safe identifiers like TMSIs that are not
easy to predict by an attacker.  Using rand() or some other
pseudo-random generator with a predictible seed like the time of the
process start is probably not the best choice here.

Using the rather strong entropy pool of /dev/urandom or getrandom()
is apparently not a good choice either: We can exhaust the entropy pool
at whch point we would have to  block/wait, which we of course cannot in
our architecture.

So what do we do?  I think we first have to differentiate on the type of
randomness needed.  Is it a random identifier like TMSI? Is it a random
challenge used in cryptographic authentication?  Is it random data used
for a key?  Those require different levels of randomness.

For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
like rand() or any other pseudo-random generator of significantly large
period is sufficient *if* it is seeded by a non-predictable value.  So
something like seeding with getrandom() result should be fine?

For random challenges in authentiation I would probably go for
direct use of urandom / getrandom().  If the entropy is exhausted, the
quality of the random numbers will get lower, but getrandom() will
always return up t 256 bytes.

For long-term stable key (Ki/Op) generation for provisioning SIM cards +
populating a HLR, I would certainly opt for using stronger randomness
sources.  However, I don't think we actually implement that anywhere, do
we?

What do you guys think?  Is there somebody on this list more
cryptographically qualified to give us proper guidance?  If you know
somebody skilled who might want to help but is not on this list, would
you invite them to join this discussion?

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


From holger at freyther.de  Wed Sep 27 13:34:22 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 27 Sep 2017 21:34:22 +0800
Subject: ctrl interface: GET a variable with parameter
In-Reply-To: <20170926140055.GB17482@ass40.sysmocom.de>
References: <20170926140055.GB17482@ass40.sysmocom.de>
Message-ID: <57A253A4-967B-48DA-96B6-72B5B277AAC0@freyther.de>


> On 26. Sep 2017, at 22:00, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> Experimenting a bit, I found that for GET commands, any tokens sent after
> the variable name are ignored, dropped on the floor and cause neither an
> error nor are evaluated.

IIRC it was modeled like a property/sysctl. E.g.

kernel.sched_domain.cpu0.domain0.min_interval

one could say variable is "kernel.sched_domain" and parameter is "cpu0"
or everything is encoded in the variable? I think we can have wildcards
in the registration of commands.

does this make sense?

holger


From msuraev at sysmocom.de  Wed Sep 27 13:50:24 2017
From: msuraev at sysmocom.de (Max)
Date: Wed, 27 Sep 2017 15:50:24 +0200
Subject: "NITB split" and implications for OsmoSGSN
In-Reply-To: <20170923041920.corov3zaqxa6udye@nataraja>
References: <20170923001130.33l63bgemlzttkgm@nataraja>
 <20170923041920.corov3zaqxa6udye@nataraja>
Message-ID: <fc10823a-6694-7542-92f6-04b37cfd1fc3@sysmocom.de>

FYI, the patch which will move nightly packages to osmo-sgsn and osmo-ggsn repos is
available at https://gerrit.osmocom.org/#/c/4056/

On 23.09.2017 06:19, Neels Hofmeyr wrote:
>
>> * start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
> yes, that is the transition. The BTS and SGSN are notably the most back- and
> forward compatible components in this transition, there isn't much difference
> except the M3UA/SCCP addition in the SGSN, which again is only needed for IuPS,
> i.e. 3G data. IIRC the entire 2G SGSN land is identical between openbsc.git and
> osmo-sgsn.git.

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






From nhofmeyr at sysmocom.de  Wed Sep 27 15:27:38 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 27 Sep 2017 17:27:38 +0200
Subject: ctrl interface: GET a variable with parameter
In-Reply-To: <57A253A4-967B-48DA-96B6-72B5B277AAC0@freyther.de>
References: <20170926140055.GB17482@ass40.sysmocom.de>
 <57A253A4-967B-48DA-96B6-72B5B277AAC0@freyther.de>
Message-ID: <20170927152738.GA28882@my.box>

On Wed, Sep 27, 2017 at 09:34:22PM +0800, Holger Freyther wrote:
> IIRC it was modeled like a property/sysctl. E.g.
> 
> kernel.sched_domain.cpu0.domain0.min_interval
>
> one could say variable is "kernel.sched_domain" and parameter is "cpu0"

There's indeed a lot more going on than I was aware of, thanks!
I can send, with current libosmocore master:

  GET 123 status-ps.imsi1234567898765

and it ends up in the status-ps command implementation. (The cmd->value remains
empty, cmd->variable is "status-ps.imsi1234567898765")

Also we do have a concept of nesting CTRL nodes separated by dots in the
variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().


I notice though that we do still have open doors for a lot of nonsense being
sent to it without proper validation or error messages.

  GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored

in effect is identical to:

  GET 42 existing-variable

So we should probably enforce that there is no ignored nonsense...

Should we also enforce a numeric command ID?
 
  GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command



Going back to the OsmoHLR CTRL commands -- they are implemented in a way that
doesn't match the CTRL interface ways. Let's collapse them.

  SET enable-ps <IMSI>
  SET disable-ps <IMSI>
  SET status-ps <IMSI>

==>

  SET subscriber.by-imsi.123456789098765.ps-enabled 1
  SET subscriber.by-imsi.123456789098765.ps-enabled 0
  GET subscriber.by-imsi.123456789098765.ps-enabled

We can also expand this later to things like

  GET subscriber.by-imsi.123456789098765.status
  SET subscriber.by-imsi.123456789098765.msisdn 2345
  GET subscriber.by-msisdn.2342.status
  SET subscriber.by-msisdn.2342.ps-enabled 0
  GET subscriber.by-imei.987654321234565.imsi

yes?

We could leave the enable-ps, disable-ps, status-ps commands in place in case
anyone is using it yet. I assume no-one is though.

~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/20170927/a7fd5f1a/attachment.bin>

From wljones at praxiseng.com  Wed Sep 27 15:50:46 2017
From: wljones at praxiseng.com (Billy Jones)
Date: Wed, 27 Sep 2017 15:50:46 +0000
Subject: pySim inconsistent on seemingly identical SIM cards
Message-ID: <2A19B4634AE6624D96CD58F84FDA9C9C5447CEB7@EXCH04.praxislan01.com>

I have two SIM card I inheritted from a previous project that I've been told came from the same vendor.  When I run `pcsc_scan` on them, I get the following output for both:

Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
  Card state: Card inserted,
  ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68

ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
+ TS = 3B --> Direct Convention
+ T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
  TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
    62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
  Category indicator byte: 55 (proprietary format)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
    SIM from sysmocom sysmoSIM-GR2

When I try to program one of the SIMs, it works fine:

$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
 > Name    : Magic
 > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
 > ICCID   : 8901001010000000017
 > MCC/MNC : 1/1
 > IMSI    : 001010000000001
 > Ki      : ffffffffffffffffffffffffffffffff
 > OPC     : f134b55cea2942ebbd213c82e084be62
 > ACC     : None

Programming ...
Done !

But on the other I get:

$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01

Insert card now (or CTRL-C to cancel)
Generated card parameters :
 > Name    : Magic
 > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
 > ICCID   : 8901001010000000017
 > MCC/MNC : 1/1
 > IMSI    : 001010000000001
 > Ki      : ffffffffffffffffffffffffffffffff
 > OPC     : 53945a5223e299bf6cec05911922442c
 > ACC     : None

Programming ...
Traceback (most recent call last):
  File "./pySim-prog.py", line 636, in <module>
    card.program(cp)
  File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
    self._scc.verify_chv(0x05, pin)
  File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
    return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
  File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
    raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9840.


I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error.  Is there any documentation explaining the magic byte values that are sent back and forth to the card?  I'm having a hard time understanding the spec by which the program is trying too communicate with the card.

Any help is greatly appreciated.

Thanks,
Billy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/b4bf9eed/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Sep 27 16:06:48 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 27 Sep 2017 18:06:48 +0200
Subject: randomness of identifiers
In-Reply-To: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
Message-ID: <20170927160648.GB19196@my.box>

On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> like rand() or any other pseudo-random generator of significantly large
> period is sufficient *if* it is seeded by a non-predictable value.  So
> something like seeding with getrandom() result should be fine?

Also matches my gut feeling there. Might also make sense to periodically
re-seed from /dev/urandom / getrandom(), like every 100 TMSIs, or based on a
timeout might be easier to implement.

> For long-term stable key (Ki/Op) generation for provisioning SIM cards +
> populating a HLR, I would certainly opt for using stronger randomness
> sources.  However, I don't think we actually implement that anywhere, do
> we?

what does openssh use for public/private keypair generation?

> What do you guys think?  Is there somebody on this list more
> cryptographically qualified to give us proper guidance?  If you know
> somebody skilled who might want to help but is not on this list, would
> you invite them to join this discussion?

I don't count myself as one of them, help is still appreciated.

~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/20170927/d221d3f4/attachment.bin>

From domi at tomcsanyi.net  Wed Sep 27 16:07:33 2017
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Wed, 27 Sep 2017 18:07:33 +0200
Subject: pySim inconsistent on seemingly identical SIM cards
In-Reply-To: <2A19B4634AE6624D96CD58F84FDA9C9C5447CEB7@EXCH04.praxislan01.com>
References: <2A19B4634AE6624D96CD58F84FDA9C9C5447CEB7@EXCH04.praxislan01.com>
Message-ID: <8765DDDD-F735-49C7-808C-CD1476A075DF@tomcsanyi.net>

Hi Billy,

Here you go:
https://eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list <https://eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list>

Good luck!
Domi


> 2017. szept. 27. d?tummal, 17:50 id?pontban Billy Jones <wljones at praxiseng.com> ?rta:
> 
> I have two SIM card I inheritted from a previous project that I've been told came from the same vendor.  When I run `pcsc_scan` on them, I get the following output for both:
> 
> Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
>   Card state: Card inserted, 
>   ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
> 
> ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
> + TS = 3B --> Direct Convention
> + T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
>   TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
>     62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
>   TB(1) = 00 --> VPP is not electrically connected
>   TC(1) = 00 --> Extra guard time: 0
> + Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
>   Category indicator byte: 55 (proprietary format)
> 
> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
>     SIM from sysmocom sysmoSIM-GR2
> 
> When I try to program one of the SIMs, it works fine:
> 
> $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
> Insert card now (or CTRL-C to cancel)
> Generated card parameters :
>  > Name    : Magic
>  > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
>  > ICCID   : 8901001010000000017
>  > MCC/MNC : 1/1
>  > IMSI    : 001010000000001
>  > Ki      : ffffffffffffffffffffffffffffffff
>  > OPC     : f134b55cea2942ebbd213c82e084be62
>  > ACC     : None
> 
> Programming ...
> Done !
> 
> But on the other I get:
> 
> $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
> 
> Insert card now (or CTRL-C to cancel)
> Generated card parameters :
>  > Name    : Magic
>  > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
>  > ICCID   : 8901001010000000017
>  > MCC/MNC : 1/1
>  > IMSI    : 001010000000001
>  > Ki      : ffffffffffffffffffffffffffffffff
>  > OPC     : 53945a5223e299bf6cec05911922442c
>  > ACC     : None
> 
> Programming ...
> Traceback (most recent call last):
>   File "./pySim-prog.py", line 636, in <module>
>     card.program(cp)
>   File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
>     self._scc.verify_chv(0x05, pin)
>   File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
>     return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
>   File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
>     raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
> RuntimeError: SW match failed ! Expected 9000 and got 9840.
> 
> 
> I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error.  Is there any documentation explaining the magic byte values that are sent back and forth to the card?  I'm having a hard time understanding the spec by which the program is trying too communicate with the card.
> 
> Any help is greatly appreciated.
> 
> Thanks,
> Billy

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

From nhofmeyr at sysmocom.de  Wed Sep 27 16:08:56 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 27 Sep 2017 18:08:56 +0200
Subject: ctrl interface: GET a variable with parameter
In-Reply-To: <4efde062-5ae6-0640-5e74-b0a3e47f765b@sysmocom.de>
References: <20170926140055.GB17482@ass40.sysmocom.de>
 <4efde062-5ae6-0640-5e74-b0a3e47f765b@sysmocom.de>
Message-ID: <20170927160856.GC19196@my.box>

On Wed, Sep 27, 2017 at 10:34:21AM +0200, Max wrote:
> On 26.09.2017 16:00, Neels Hofmeyr wrote:
> > One step further would be to pick an identification trait from imsi, msisdn or imei...
> >
> >   GET 1 subscriber imsi=123456789087654 msisdn imeisv
> >   GET 1 subscriber msisdn=12345 imsi imeisv
> >   GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
> Can't we just skip parameters which do not have values and simply use
> 
> "GET 1 subscriber msisdn=12345"?

For
   GET 1 subscriber msisdn=12345 imsi imeisv
my idea was to return imsi and imeisv values for subscriber selected by msisdn=12345.

But this superseded by another idea in another mail...

~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/20170927/0511fa7e/attachment.bin>

From wljones at praxiseng.com  Wed Sep 27 17:35:07 2017
From: wljones at praxiseng.com (Billy Jones)
Date: Wed, 27 Sep 2017 17:35:07 +0000
Subject: pySim inconsistent on seemingly identical SIM cards
In-Reply-To: <8765DDDD-F735-49C7-808C-CD1476A075DF@tomcsanyi.net>
References: <2A19B4634AE6624D96CD58F84FDA9C9C5447CEB7@EXCH04.praxislan01.com>
 <8765DDDD-F735-49C7-808C-CD1476A075DF@tomcsanyi.net>
Message-ID: <2A19B4634AE6624D96CD58F84FDA9C9C5447D121@EXCH04.praxislan01.com>

Domi,

Thank you for the link!

So am I right in concluding that the SIM has a PIN associated with it and I?m not sending the correct one (from the code it looks like it?s sending ?DDDDDDDD? as the default since I?m not specifying it in the command line)?

Thanks again,
Billy

From: Tomcs?nyi Domonkos [mailto:domi at tomcsanyi.net]
Sent: Wednesday, September 27, 2017 12:08 PM
To: Billy Jones
Cc: openbsc at lists.osmocom.org
Subject: Re: pySim inconsistent on seemingly identical SIM cards

Hi Billy,

Here you go:
https://eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list

Good luck!
Domi


2017. szept. 27. d?tummal, 17:50 id?pontban Billy Jones <wljones at praxiseng.com<mailto:wljones at praxiseng.com>> ?rta:

I have two SIM card I inheritted from a previous project that I've been told came from the same vendor.  When I run `pcsc_scan` on them, I get the following output for both:

Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
  Card state: Card inserted,
  ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68

ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
+ TS = 3B --> Direct Convention
+ T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
  TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
    62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
  Category indicator byte: 55 (proprietary format)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
    SIM from sysmocom sysmoSIM-GR2

When I try to program one of the SIMs, it works fine:

$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
 > Name    : Magic
 > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
 > ICCID   : 8901001010000000017
 > MCC/MNC : 1/1
 > IMSI    : 001010000000001
 > Ki      : ffffffffffffffffffffffffffffffff
 > OPC     : f134b55cea2942ebbd213c82e084be62
 > ACC     : None

Programming ...
Done !

But on the other I get:

$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01

Insert card now (or CTRL-C to cancel)
Generated card parameters :
 > Name    : Magic
 > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
 > ICCID   : 8901001010000000017
 > MCC/MNC : 1/1
 > IMSI    : 001010000000001
 > Ki      : ffffffffffffffffffffffffffffffff
 > OPC     : 53945a5223e299bf6cec05911922442c
 > ACC     : None

Programming ...
Traceback (most recent call last):
  File "./pySim-prog.py", line 636, in <module>
    card.program(cp)
  File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
    self._scc.verify_chv(0x05, pin)
  File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
    return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
  File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
    raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9840.


I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error.  Is there any documentation explaining the magic byte values that are sent back and forth to the card?  I'm having a hard time understanding the spec by which the program is trying too communicate with the card.

Any help is greatly appreciated.

Thanks,
Billy

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

From domi at tomcsanyi.net  Wed Sep 27 21:08:22 2017
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Wed, 27 Sep 2017 23:08:22 +0200
Subject: pySim inconsistent on seemingly identical SIM cards
In-Reply-To: <2A19B4634AE6624D96CD58F84FDA9C9C5447D121@EXCH04.praxislan01.com>
References: <2A19B4634AE6624D96CD58F84FDA9C9C5447CEB7@EXCH04.praxislan01.com>
 <8765DDDD-F735-49C7-808C-CD1476A075DF@tomcsanyi.net>
 <2A19B4634AE6624D96CD58F84FDA9C9C5447D121@EXCH04.praxislan01.com>
Message-ID: <048BFC3B-BAA9-476C-9EBB-3232C4E111B0@tomcsanyi.net>

Hi Billy,

Yes, according to the code you are trying with 4444444444444444, which is indeed DDDDDDDD.
https://github.com/osmocom/pysim/blob/master/pySim/cards.py#L375 <https://github.com/osmocom/pysim/blob/master/pySim/cards.py#L375>

It is important to note that this is not the PIN-code you enter when you put the card into a phone, it is the super-admin PIN code/ADM key needed for programming if I understand the code correctly.

Cheers,
Domi


> 2017. szept. 27. d?tummal, 19:35 id?pontban Billy Jones <wljones at praxiseng.com> ?rta:
> 
> Domi,
>  
> Thank you for the link!
>  
> So am I right in concluding that the SIM has a PIN associated with it and I?m not sending the correct one (from the code it looks like it?s sending ?DDDDDDDD? as the default since I?m not specifying it in the command line)?
>  
> Thanks again,
> Billy
>  
> From: Tomcs?nyi Domonkos [mailto:domi at tomcsanyi.net] 
> Sent: Wednesday, September 27, 2017 12:08 PM
> To: Billy Jones
> Cc: openbsc at lists.osmocom.org
> Subject: Re: pySim inconsistent on seemingly identical SIM cards
>  
> Hi Billy,
>  
> Here you go:
> https://eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list <https://eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list>
>  
> Good luck!
> Domi
>  
>  
> 2017. szept. 27. d?tummal, 17:50 id?pontban Billy Jones <wljones at praxiseng.com <mailto:wljones at praxiseng.com>> ?rta:
>  
> I have two SIM card I inheritted from a previous project that I've been told came from the same vendor.  When I run `pcsc_scan` on them, I get the following output for both:
> 
> Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
>   Card state: Card inserted, 
>   ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
> 
> ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
> + TS = 3B --> Direct Convention
> + T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
>   TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
>     62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
>   TB(1) = 00 --> VPP is not electrically connected
>   TC(1) = 00 --> Extra guard time: 0
> + Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
>   Category indicator byte: 55 (proprietary format)
> 
> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
>     SIM from sysmocom sysmoSIM-GR2
> 
> When I try to program one of the SIMs, it works fine:
> 
> $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
> Insert card now (or CTRL-C to cancel)
> Generated card parameters :
>  > Name    : Magic
>  > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
>  > ICCID   : 8901001010000000017
>  > MCC/MNC : 1/1
>  > IMSI    : 001010000000001
>  > Ki      : ffffffffffffffffffffffffffffffff
>  > OPC     : f134b55cea2942ebbd213c82e084be62
>  > ACC     : None
> 
> Programming ...
> Done !
> 
> But on the other I get:
> 
> $ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
> 
> Insert card now (or CTRL-C to cancel)
> Generated card parameters :
>  > Name    : Magic
>  > SMSP    : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
>  > ICCID   : 8901001010000000017
>  > MCC/MNC : 1/1
>  > IMSI    : 001010000000001
>  > Ki      : ffffffffffffffffffffffffffffffff
>  > OPC     : 53945a5223e299bf6cec05911922442c
>  > ACC     : None
> 
> Programming ...
> Traceback (most recent call last):
>   File "./pySim-prog.py", line 636, in <module>
>     card.program(cp)
>   File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
>     self._scc.verify_chv(0x05, pin)
>   File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
>     return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
>   File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
>     raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
> RuntimeError: SW match failed ! Expected 9000 and got 9840.
> 
> 
> I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error.  Is there any documentation explaining the magic byte values that are sent back and forth to the card?  I'm having a hard time understanding the spec by which the program is trying too communicate with the card.
> 
> Any help is greatly appreciated.
> 
> Thanks,
> Billy

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

From exuberant.kathryn.heckman at gmail.com  Wed Sep 27 21:37:36 2017
From: exuberant.kathryn.heckman at gmail.com (Kathryn Heckman)
Date: Wed, 27 Sep 2017 17:37:36 -0400
Subject: Retrieve OP from OPc and Ki
Message-ID: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>

Hi,

Is there any way to retrieve the value of OP from OPc and Ki?

Best,
Kathryn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/ab8fcea8/attachment.htm>

From domi at tomcsanyi.net  Wed Sep 27 21:40:25 2017
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Wed, 27 Sep 2017 23:40:25 +0200
Subject: Retrieve OP from OPc and Ki
In-Reply-To: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
References: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
Message-ID: <8575AFA6-B0C4-476E-9BF0-4D8BFAAA2DA3@tomcsanyi.net>

HI Kathryn,

As far as I remember there is no way. I remember looking into the way OPc is generated, and it is non-reversible.

Cheers,
Domi


> 2017. szept. 27. d?tummal, 23:37 id?pontban Kathryn Heckman <exuberant.kathryn.heckman at gmail.com> ?rta:
> 
> Hi,
> 
> Is there any way to retrieve the value of OP from OPc and Ki?
> 
> Best,
> Kathryn



From nhofmeyr at sysmocom.de  Wed Sep 27 22:22:31 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 28 Sep 2017 00:22:31 +0200
Subject: branches in openbsc.git
Message-ID: <20170927222231.GA25140@my.box>

another call for anyone aware of important branches on openbsc.git to please
name them, so that they can be migrated to the new repositories.
But foremost, please name them, thanks!

~N
-------------- 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/20170928/4ef077c0/attachment.bin>

From laforge at gnumonks.org  Wed Sep 27 23:05:09 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 28 Sep 2017 07:05:09 +0800
Subject: branches in openbsc.git
In-Reply-To: <20170927222231.GA25140@my.box>
References: <20170927222231.GA25140@my.box>
Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja>

On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
> another call for anyone aware of important branches on openbsc.git to please
> name them, so that they can be migrated to the new repositories.
> But foremost, please name them, thanks!

>From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc

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


From laforge at gnumonks.org  Wed Sep 27 23:15:01 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 28 Sep 2017 07:15:01 +0800
Subject: randomness of identifiers
In-Reply-To: <20170927160648.GB19196@my.box>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
 <20170927160648.GB19196@my.box>
Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja>

Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> > like rand() or any other pseudo-random generator of significantly large
> > period is sufficient *if* it is seeded by a non-predictable value.  So
> > something like seeding with getrandom() result should be fine?

> Might also make sense to periodically re-seed from /dev/urandom /
> getrandom(), like every 100 TMSIs, or based on a timeout might be
> easier to implement.

I would try to avoid any predictability here.  Having a fixed time
interval would be known to an attackers.  So if he was somehow able to
reduce/exhaust the entropy at the known time for re-seeding, it would be
bad.

Similar for "every 100 TMSIs", which is something under control of any
attacker as he can control the number of location updates via the public
radio interface [to some extent] and thus control the time at whcih
re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you
want to ideally do it at a non-predictable and non-controllable point in
time.  Like a random time interval ;)

> > For long-term stable key (Ki/Op) generation for provisioning SIM cards +
> > populating a HLR, I would certainly opt for using stronger randomness
> > sources.  However, I don't think we actually implement that anywhere, do
> > we?
> 
> what does openssh use for public/private keypair generation?

I'm not sure you can compare the requirements for generation of RSA
public/private keys with those for generation of symmetric keys. You can
find different recommendations in the literature.  But I guess that's
mainly due to the fact that people usually assume you have long-term
stable public/private keys and short-lived symmetric session keys.  In
our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for
generation of TMSIs and for random numbers used in authentication
challenges.  K/OPc pair generation is not supported in current Osmocom
tools anyway, as we presume the SIM cards already have sufficiently
random key material and those keys are entered into the HLR.

Regards,
	Harald

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


From laforge at gnumonks.org  Wed Sep 27 22:52:28 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 28 Sep 2017 06:52:28 +0800
Subject: Retrieve OP from OPc and Ki
In-Reply-To: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
References: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja>

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc
values.

If you could just revert that operation, there would be no [security]
advantage of card-individual OPc values over a global OP value, and
hence that entire option could be dropped from the specifications
altogether.

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


From laforge at gnumonks.org  Wed Sep 27 22:50:03 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 28 Sep 2017 06:50:03 +0800
Subject: ctrl interface: GET a variable with parameter
In-Reply-To: <20170927152738.GA28882@my.box>
References: <20170926140055.GB17482@ass40.sysmocom.de>
 <57A253A4-967B-48DA-96B6-72B5B277AAC0@freyther.de>
 <20170927152738.GA28882@my.box>
Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja>

Hi Neels,

On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
> Also we do have a concept of nesting CTRL nodes separated by dots in the
> variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().

correct.

> I notice though that we do still have open doors for a lot of nonsense being
> sent to it without proper validation or error messages.
> 
>   GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
> 
> in effect is identical to:
> 
>   GET 42 existing-variable
> 
> So we should probably enforce that there is no ignored nonsense...

I agree.

> Should we also enforce a numeric command ID?

I'm not following here. Where would that numeric command ID comning
from?

>   GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command

this is also not intended, I'm quite sure.

> Going back to the OsmoHLR CTRL commands -- they are implemented in a way that
> doesn't match the CTRL interface ways. Let's collapse them.
> 
>   SET enable-ps <IMSI>
>   SET disable-ps <IMSI>
>   SET status-ps <IMSI>

indeed, this is not proper.

>   SET subscriber.by-imsi.123456789098765.ps-enabled 1
>   SET subscriber.by-imsi.123456789098765.ps-enabled 0
>   GET subscriber.by-imsi.123456789098765.ps-enabled

makes a lot of sense to me.

> We can also expand this later to things like
> 
>   GET subscriber.by-imsi.123456789098765.status
>   SET subscriber.by-imsi.123456789098765.msisdn 2345
>   GET subscriber.by-msisdn.2342.status
>   SET subscriber.by-msisdn.2342.ps-enabled 0
>   GET subscriber.by-imei.987654321234565.imsi

looks good!

> We could leave the enable-ps, disable-ps, status-ps commands in place in case
> anyone is using it yet. I assume no-one is though.

I don't think we need to keep compatibility 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment.bin>

From exuberant.kathryn.heckman at gmail.com  Thu Sep 28 01:46:27 2017
From: exuberant.kathryn.heckman at gmail.com (Kathryn Heckman)
Date: Wed, 27 Sep 2017 21:46:27 -0400
Subject: Retrieve OP from OPc and Ki
In-Reply-To: <20170927225228.u4udbuhk2fyebrl5@nataraja>
References: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
 <20170927225228.u4udbuhk2fyebrl5@nataraja>
Message-ID: <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>

I really appreciate your quick replies.

I have a USIM that I wanted to program. However, I am getting the runtime
error for exceeding the number of attempts to enter the ADM1 key. Is there
any fix for it?

--
Kathryn

On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Kathryn,
>
> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> > Is there any way to retrieve the value of OP from OPc and Ki?
>
> No, that defeats the entire purpose of having card-individual OPc
> values.
>
> If you could just revert that operation, there would be no [security]
> advantage of card-individual OPc values over a global OP value, and
> hence that entire option could be dropped from the specifications
> altogether.
>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment.htm>

From mychaela.falconia at gmail.com  Thu Sep 28 02:04:35 2017
From: mychaela.falconia at gmail.com (Mychaela Falconia)
Date: Wed, 27 Sep 2017 18:04:35 -0800
Subject: Retrieve OP from OPc and Ki
In-Reply-To: <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>
References: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
 <20170927225228.u4udbuhk2fyebrl5@nataraja>
 <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>
Message-ID: <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com>

On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com> wrote:
> I have a USIM that I wanted to program. However, I am getting the runtime
> error for exceeding the number of attempts to enter the ADM1 key. Is there
> any fix for it?

Someone please correct me if I am wrong, but I would assume that
having exceeded the number of attempts to enter the ADM1 key means
that the USIM is bricked beyond recovery.

But the sysmoUSIM cards sold at shop.sysmocom.de are fairly
inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big
of a tragedy - or is there another dimension to this problem which I
am missing?

If you are anywhere near local to me (California, USA) I could give
you one of my sysmoUSIM cards, but I am guessing it probably won't
help you as I bought the cheaper version without the ADM1 keys - for
my application (production testing of my GSM MS hardware) it doesn't
matter what the programming of the (U)SIM happens to be.

M~


From domi at tomcsanyi.net  Thu Sep 28 02:35:24 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
Subject: Retrieve OP from OPc and Ki
In-Reply-To: <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com>
References: <CAHmN-qTC2kTkZMYusnDAHcnFhhrC6FXM1L7m6TMaAFjC8M06vw@mail.gmail.com>
 <20170927225228.u4udbuhk2fyebrl5@nataraja>
 <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>
 <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com>
Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net>

Hi Kathryn and Mychaela,

2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia at gmail.com> ?rta:
> Someone please correct me if I am wrong, but I would assume that
> having exceeded the number of attempts to enter the ADM1 key means
> that the USIM is bricked beyond recovery.

This is my understanding as well.

Cheers,

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

From holger at freyther.de  Thu Sep 28 04:04:04 2017
From: holger at freyther.de (Holger Freyther)
Date: Thu, 28 Sep 2017 12:04:04 +0800
Subject: randomness of identifiers
In-Reply-To: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
Message-ID: <83B20A61-C1DD-4335-8C5E-3F4D8AEE017E@freyther.de>


> On 27. Sep 2017, at 19:57, Harald Welte <laforge at gnumonks.org> wrote:
> 

> For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> like rand() or any other pseudo-random generator of significantly large
> period is sufficient *if* it is seeded by a non-predictable value.  So
> something like seeding with getrandom() result should be fine?

GLIBC rand() maybe but "any other" not. E.g. if it is a Mersenne Twister
than observing ~624 TMSIs could be enough to predict past and future state.

Picking something like RAND_bytes of OpenSSL for TMSIs seems to be the
best way. It will re-seed itself (and we are not forking). If the OpenSSL
dependency is too bad (license compatibility, the move to the Apache license
could help us here for GPLv3+ software) then maybe the second best option
is to take a "Fortuna"[1] implementation from somewhere?

holger


[1] https://en.wikipedia.org/wiki/Fortuna_(PRNG)


From msuraev at sysmocom.de  Thu Sep 28 08:22:35 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 28 Sep 2017 10:22:35 +0200
Subject: branches in openbsc.git
In-Reply-To: <20170927222231.GA25140@my.box>
References: <20170927222231.GA25140@my.box>
Message-ID: <da2ff43e-a1fb-0696-f73f-cfc9a5a47ad6@sysmocom.de>

All my branches ../max/.. can be safely removed from the openbsc repo.

-- 
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 Goran.Popovic at kapsch.net  Thu Sep 28 09:07:56 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Thu, 28 Sep 2017 09:07:56 +0000
Subject: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
Message-ID: <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>

HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran




-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of openbsc-request at lists.osmocom.org
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc at lists.osmocom.org
Subject: OpenBSC Digest, Vol 35, Issue 30

Send OpenBSC mailing list submissions to
	openbsc at lists.osmocom.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
	openbsc-request at lists.osmocom.org

You can reach the person managing the list at
	openbsc-owner at lists.osmocom.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."


Today's Topics:

   1. Re: branches in openbsc.git (Harald Welte)
   2. Re: randomness of identifiers (Harald Welte)
   3. Re: Retrieve OP from OPc and Ki (Harald Welte)
   4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
   5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
   6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
   7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte <laforge at gnumonks.org>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Cc: openbsc at lists.osmocom.org
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2 at nataraja>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
> another call for anyone aware of important branches on openbsc.git to 
> please name them, so that they can be migrated to the new repositories.
> But foremost, please name them, thanks!

>From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc

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


------------------------------

Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte <laforge at gnumonks.org>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Cc: openbsc at lists.osmocom.org
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that 
> > something like rand() or any other pseudo-random generator of 
> > significantly large period is sufficient *if* it is seeded by a 
> > non-predictable value.  So something like seeding with getrandom() result should be fine?

> Might also make sense to periodically re-seed from /dev/urandom / 
> getrandom(), like every 100 TMSIs, or based on a timeout might be 
> easier to implement.

I would try to avoid any predictability here.  Having a fixed time interval would be known to an attackers.  So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.

Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time.  Like a random time interval ;)

> > For long-term stable key (Ki/Op) generation for provisioning SIM 
> > cards + populating a HLR, I would certainly opt for using stronger 
> > randomness sources.  However, I don't think we actually implement 
> > that anywhere, do we?
> 
> what does openssh use for public/private keypair generation?

I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature.  But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys.  In our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges.  K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.

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)


------------------------------

Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte <laforge at gnumonks.org>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5 at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc values.

If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.

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)


------------------------------

Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte <laforge at gnumonks.org>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Cc: Holger Freyther <holger at freyther.de>, openbsc at lists.osmocom.org
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu at nataraja>
Content-Type: text/plain; charset="us-ascii"

Hi Neels,

On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
> Also we do have a concept of nesting CTRL nodes separated by dots in 
> the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().

correct.

> I notice though that we do still have open doors for a lot of nonsense 
> being sent to it without proper validation or error messages.
> 
>   GET 42 existing-variable.trailing.names.ignored more nonsense 
> following being ignored
> 
> in effect is identical to:
> 
>   GET 42 existing-variable
> 
> So we should probably enforce that there is no ignored nonsense...

I agree.

> Should we also enforce a numeric command ID?

I'm not following here. Where would that numeric command ID comning from?

>   GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command

this is also not intended, I'm quite sure.

> Going back to the OsmoHLR CTRL commands -- they are implemented in a 
> way that doesn't match the CTRL interface ways. Let's collapse them.
> 
>   SET enable-ps <IMSI>
>   SET disable-ps <IMSI>
>   SET status-ps <IMSI>

indeed, this is not proper.

>   SET subscriber.by-imsi.123456789098765.ps-enabled 1
>   SET subscriber.by-imsi.123456789098765.ps-enabled 0
>   GET subscriber.by-imsi.123456789098765.ps-enabled

makes a lot of sense to me.

> We can also expand this later to things like
> 
>   GET subscriber.by-imsi.123456789098765.status
>   SET subscriber.by-imsi.123456789098765.msisdn 2345
>   GET subscriber.by-msisdn.2342.status
>   SET subscriber.by-msisdn.2342.ps-enabled 0
>   GET subscriber.by-imei.987654321234565.imsi

looks good!

> We could leave the enable-ps, disable-ps, status-ps commands in place 
> in case anyone is using it yet. I assume no-one is though.

I don't think we need to keep compatibility 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin>

------------------------------

Message: 5
Date: Wed, 27 Sep 2017 21:46:27 -0400
From: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
To: Harald Welte <laforge at gnumonks.org>
Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
	<CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I really appreciate your quick replies.

I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it?

--
Kathryn

On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Kathryn,
>
> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> > Is there any way to retrieve the value of OP from OPc and Ki?
>
> No, that defeats the entire purpose of having card-individual OPc 
> values.
>
> If you could just revert that operation, there would be no [security] 
> advantage of card-individual OPc values over a global OP value, and 
> hence that entire option could be dropped from the specifications 
> altogether.
>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 27 Sep 2017 18:04:35 -0800
From: Mychaela Falconia <mychaela.falconia at gmail.com>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
Cc: openbsc <openbsc at lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
	<CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com> wrote:
> I have a USIM that I wanted to program. However, I am getting the 
> runtime error for exceeding the number of attempts to enter the ADM1 
> key. Is there any fix for it?

Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery.

But the sysmoUSIM cards sold at shop.sysmocom.de are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing?

If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be.

M~


------------------------------

Message: 7
Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
From: Tomcs?nyi, Domonkos <domi at tomcsanyi.net>
To: Mychaela Falconia <mychaela.falconia at gmail.com>
Cc: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>, openbsc
	<openbsc at lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net>
Content-Type: text/plain; charset="utf-8"

Hi Kathryn and Mychaela,

2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia at gmail.com> ?rta:
> Someone please correct me if I am wrong, but I would assume that 
> having exceeded the number of attempts to enter the ADM1 key means 
> that the USIM is bricked beyond recovery.

This is my understanding as well.

Cheers,

Domi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OpenBSC mailing list
OpenBSC at lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/openbsc


------------------------------

End of OpenBSC Digest, Vol 35, Issue 30
***************************************



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



From msuraev at sysmocom.de  Thu Sep 28 09:45:46 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 28 Sep 2017 11:45:46 +0200
Subject: randomness of identifiers
In-Reply-To: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
References: <20170927115743.qkd52rwhf6xtwmuu@nataraja>
Message-ID: <5fd5d15e-460c-3483-7950-74ad2c056719@sysmocom.de>

Hi.

Thanks for bringing it up. I think some clarifications about the current
implementation are required - see below.

On 27.09.2017 13:57, Harald Welte wrote:
> Using the rather strong entropy pool of /dev/urandom or getrandom()
> is apparently not a good choice either: We can exhaust the entropy pool
> at whch point we would have to  block/wait, which we of course cannot in
> our architecture.

Note: current implementation available in https://gerrit.osmocom.org/#/c/1526/ will
never ever block. It will fallback to insecure rand() if there's not enough entropy
in the pool and let caller know about it.

This is exactly what the existing code does.

> So what do we do?  I think we first have to differentiate on the type of
> randomness needed.  Is it a random identifier like TMSI? Is it a random
> challenge used in cryptographic authentication?  Is it random data used
> for a key?  Those require different levels of randomness.

I think before adding all this complexity we should first check how realistic the
entropy exhaustion in practice?
The implementation in https://gerrit.osmocom.org/#/c/1526/ does not allow you to
request more than 16 bytes of random data at once. And such requests could not come
at arbitrary speed either - attacker have to trigger certain events which would
result in random identifier generation.

Linux kernel constantly gather entropy. Is it possible for an attacker to exhaust it
faster than kernel gathers it?

Also, it's important to remember that the consideration above are for "the ideal
system we want to build". If we compare it with the current implementation, than
https://gerrit.osmocom.org/#/c/1526/ can be merged right away:
- it uses secure random data if it's available
- it falls back to insecure random generator if not
- it gives exactly the same log messages about it as the current code

So there are actually 2 questions in here:
- can we merge gerrit #1526?
- can we do even better?

IMHO, the answers are "yeah" and "should we?" :)

-- 
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 domi at tomcsanyi.net  Thu Sep 28 11:07:25 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Thu, 28 Sep 2017 13:07:25 +0200 (CEST)
Subject: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
 <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
Message-ID: <74FC000C-ACC2-445C-A53D-A3055A3AFFF1@tomcsanyi.net>

Hi Goran,

Without any exact details, like error messages and commands that you tried we cannot give you much help sadly.

Please provide all details possible in text format, and I?m sure someone will help.

Regards,
Domi


2017. szept. 28. d?tummal, 11:18 id?pontban Popovic Goran <Goran.Popovic at kapsch.net> ?rta:

> HI,
> My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
> Also tried Vagrant IuH image, but there is issue with permisions,
> Is there a way to get some help for solving this issues,
> Thanks
> Goran
> 
> 
> 
> 
> -----Original Message-----
> From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of openbsc-request at lists.osmocom.org
> Sent: Thursday, September 28, 2017 4:36 AM
> To: openbsc at lists.osmocom.org
> Subject: OpenBSC Digest, Vol 35, Issue 30
> 
> Send OpenBSC mailing list submissions to
>    openbsc at lists.osmocom.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>    openbsc-request at lists.osmocom.org
> 
> You can reach the person managing the list at
>    openbsc-owner at lists.osmocom.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: branches in openbsc.git (Harald Welte)
>   2. Re: randomness of identifiers (Harald Welte)
>   3. Re: Retrieve OP from OPc and Ki (Harald Welte)
>   4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
>   5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
>   6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
>   7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 28 Sep 2017 07:05:09 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: branches in openbsc.git
> Message-ID: <20170927230509.pw4xug7jntrfvts2 at nataraja>
> Content-Type: text/plain; charset=us-ascii
> 
>> On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
>> another call for anyone aware of important branches on openbsc.git to 
>> please name them, so that they can be migrated to the new repositories.
>> But foremost, please name them, thanks!
> 
>> From "my" branches, I can see the following:
> * laforge/bssgp_fc -> osmo-sgsn
> * laforge/gprs-suspend -> osmo-bsc
> * laforge/power_control -> osmo-bsc
> 
> -- 
> - 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)
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 28 Sep 2017 07:15:01 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: randomness of identifiers
> Message-ID: <20170927231501.zyqrali3onodi4iw at nataraja>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Neels,
> 
>> On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
>>> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
>>> For TMSI allocation, my "cryptographic gut feeling"[tm] is that 
>>> something like rand() or any other pseudo-random generator of 
>>> significantly large period is sufficient *if* it is seeded by a 
>>> non-predictable value.  So something like seeding with getrandom() result should be fine?
> 
>> Might also make sense to periodically re-seed from /dev/urandom / 
>> getrandom(), like every 100 TMSIs, or based on a timeout might be 
>> easier to implement.
> 
> I would try to avoid any predictability here.  Having a fixed time interval would be known to an attackers.  So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.
> 
> Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.
> 
> Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time.  Like a random time interval ;)
> 
>>> For long-term stable key (Ki/Op) generation for provisioning SIM 
>>> cards + populating a HLR, I would certainly opt for using stronger 
>>> randomness sources.  However, I don't think we actually implement 
>>> that anywhere, do we?
>> 
>> what does openssh use for public/private keypair generation?
> 
> I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature.  But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys.  In our case, it's long-lived symmetric keys.
> 
> But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges.  K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.
> 
> 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)
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 28 Sep 2017 06:52:28 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID: <20170927225228.u4udbuhk2fyebrl5 at nataraja>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Kathryn,
> 
>> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
>> Is there any way to retrieve the value of OP from OPc and Ki?
> 
> No, that defeats the entire purpose of having card-individual OPc values.
> 
> If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.
> 
> 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)
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 28 Sep 2017 06:50:03 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: Holger Freyther <holger at freyther.de>, openbsc at lists.osmocom.org
> Subject: Re: ctrl interface: GET a variable with parameter
> Message-ID: <20170927225003.ix4qgulake4gugyu at nataraja>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Neels,
> 
>> On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
>> Also we do have a concept of nesting CTRL nodes separated by dots in 
>> the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
> 
> correct.
> 
>> I notice though that we do still have open doors for a lot of nonsense 
>> being sent to it without proper validation or error messages.
>> 
>>  GET 42 existing-variable.trailing.names.ignored more nonsense 
>> following being ignored
>> 
>> in effect is identical to:
>> 
>>  GET 42 existing-variable
>> 
>> So we should probably enforce that there is no ignored nonsense...
> 
> I agree.
> 
>> Should we also enforce a numeric command ID?
> 
> I'm not following here. Where would that numeric command ID comning from?
> 
>>  GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
> 
> this is also not intended, I'm quite sure.
> 
>> Going back to the OsmoHLR CTRL commands -- they are implemented in a 
>> way that doesn't match the CTRL interface ways. Let's collapse them.
>> 
>>  SET enable-ps <IMSI>
>>  SET disable-ps <IMSI>
>>  SET status-ps <IMSI>
> 
> indeed, this is not proper.
> 
>>  SET subscriber.by-imsi.123456789098765.ps-enabled 1
>>  SET subscriber.by-imsi.123456789098765.ps-enabled 0
>>  GET subscriber.by-imsi.123456789098765.ps-enabled
> 
> makes a lot of sense to me.
> 
>> We can also expand this later to things like
>> 
>>  GET subscriber.by-imsi.123456789098765.status
>>  SET subscriber.by-imsi.123456789098765.msisdn 2345
>>  GET subscriber.by-msisdn.2342.status
>>  SET subscriber.by-msisdn.2342.ps-enabled 0
>>  GET subscriber.by-imei.987654321234565.imsi
> 
> looks good!
> 
>> We could leave the enable-ps, disable-ps, status-ps commands in place 
>> in case anyone is using it yet. I assume no-one is though.
> 
> I don't think we need to keep compatibility 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)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin>
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 27 Sep 2017 21:46:27 -0400
> From: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> To: Harald Welte <laforge at gnumonks.org>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID:
>    <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I really appreciate your quick replies.
> 
> I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it?
> 
> --
> Kathryn
> 
>> On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org> wrote:
>> 
>> Hi Kathryn,
>> 
>>> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
>>> Is there any way to retrieve the value of OP from OPc and Ki?
>> 
>> No, that defeats the entire purpose of having card-individual OPc 
>> values.
>> 
>> If you could just revert that operation, there would be no [security] 
>> advantage of card-individual OPc values over a global OP value, and 
>> hence that entire option could be dropped from the specifications 
>> altogether.
>> 
>> 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)
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 27 Sep 2017 18:04:35 -0800
> From: Mychaela Falconia <mychaela.falconia at gmail.com>
> To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> Cc: openbsc <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID:
>    <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
>> On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com> wrote:
>> I have a USIM that I wanted to program. However, I am getting the 
>> runtime error for exceeding the number of attempts to enter the ADM1 
>> key. Is there any fix for it?
> 
> Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery.
> 
> But the sysmoUSIM cards sold at shop.sysmocom.de are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing?
> 
> If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be.
> 
> M~
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
> From: Tomcs?nyi, Domonkos <domi at tomcsanyi.net>
> To: Mychaela Falconia <mychaela.falconia at gmail.com>
> Cc: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>, openbsc
>    <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Kathryn and Mychaela,
> 
> 2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia at gmail.com> ?rta:
>> Someone please correct me if I am wrong, but I would assume that 
>> having exceeded the number of attempts to enter the ADM1 key means 
>> that the USIM is bricked beyond recovery.
> 
> This is my understanding as well.
> 
> Cheers,
> 
> Domi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
> 
> 
> ------------------------------
> 
> End of OpenBSC Digest, Vol 35, Issue 30
> ***************************************
> 
> 
> 
> The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/b4bc9819/attachment.htm>

From Goran.Popovic at kapsch.net  Thu Sep 28 11:34:58 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Thu, 28 Sep 2017 11:34:58 +0000
Subject: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <74FC000C-ACC2-445C-A53D-A3055A3AFFF1@tomcsanyi.net>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
 <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
 <74FC000C-ACC2-445C-A53D-A3055A3AFFF1@tomcsanyi.net>
Message-ID: <308DD9881922A94187C6359714B51425BC074EAB@S900X023.kapsch.co.at>

Hi,
Thank you very much for your response,
This make me believe in this project, I have just found that there are released Nightly Builds for Osmocom GSM related software.
I will reinstall my server with one of this builds and try everything again,
Basically I was following procedure from Site, on my Debian server but was stucked with dependencies which I were not able to compile, Libosmo-sccp, Libosmo-netif, libosmo-abis
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source
I will come back with questions after I tried again.
BR
Goran






From: Tomcs?nyi, Domonkos [mailto:domi at tomcsanyi.net]
Sent: Thursday, September 28, 2017 1:07 PM
To: Popovic Goran <Goran.Popovic at kapsch.net>
Cc: openbsc at lists.osmocom.org
Subject: Re: OpenBSC Digest, Vol 35, Issue 30

Hi Goran,

Without any exact details, like error messages and commands that you tried we cannot give you much help sadly.

Please provide all details possible in text format, and I?m sure someone will help.

Regards,
Domi

2017. szept. 28. d?tummal, 11:18 id?pontban Popovic Goran <Goran.Popovic at kapsch.net<mailto:Goran.Popovic at kapsch.net>> ?rta:
HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran




-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: OpenBSC Digest, Vol 35, Issue 30

Send OpenBSC mailing list submissions to
   openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>

To subscribe or unsubscribe via the World Wide Web, visit
   https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
   openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>

You can reach the person managing the list at
   openbsc-owner at lists.osmocom.org<mailto:openbsc-owner at lists.osmocom.org>

When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."


Today's Topics:

  1. Re: branches in openbsc.git (Harald Welte)
  2. Re: randomness of identifiers (Harald Welte)
  3. Re: Retrieve OP from OPc and Ki (Harald Welte)
  4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
  5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
  6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
  7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2 at nataraja<mailto:20170927230509.pw4xug7jntrfvts2 at nataraja>>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:

another call for anyone aware of important branches on openbsc.git to
please name them, so that they can be migrated to the new repositories.
But foremost, please name them, thanks!


From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc

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


------------------------------

Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw at nataraja<mailto:20170927231501.zyqrali3onodi4iw at nataraja>>
Content-Type: text/plain; charset=us-ascii

Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:

On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
For TMSI allocation, my "cryptographic gut feeling"[tm] is that
something like rand() or any other pseudo-random generator of
significantly large period is sufficient *if* it is seeded by a
non-predictable value.  So something like seeding with getrandom() result should be fine?


Might also make sense to periodically re-seed from /dev/urandom /
getrandom(), like every 100 TMSIs, or based on a timeout might be
easier to implement.

I would try to avoid any predictability here.  Having a fixed time interval would be known to an attackers.  So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.

Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time.  Like a random time interval ;)


For long-term stable key (Ki/Op) generation for provisioning SIM
cards + populating a HLR, I would certainly opt for using stronger
randomness sources.  However, I don't think we actually implement
that anywhere, do we?

what does openssh use for public/private keypair generation?

I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature.  But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys.  In our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges.  K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.

Regards,
   Harald

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


------------------------------

Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
Cc: "openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>" <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5 at nataraja<mailto:20170927225228.u4udbuhk2fyebrl5 at nataraja>>
Content-Type: text/plain; charset=us-ascii

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:

Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc values.

If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.

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


------------------------------

Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: Holger Freyther <holger at freyther.de<mailto:holger at freyther.de>>, openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu at nataraja<mailto:20170927225003.ix4qgulake4gugyu at nataraja>>
Content-Type: text/plain; charset="us-ascii"

Hi Neels,

On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:

Also we do have a concept of nesting CTRL nodes separated by dots in
the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().

correct.


I notice though that we do still have open doors for a lot of nonsense
being sent to it without proper validation or error messages.

 GET 42 existing-variable.trailing.names.ignored more nonsense
following being ignored

in effect is identical to:

 GET 42 existing-variable

So we should probably enforce that there is no ignored nonsense...

I agree.


Should we also enforce a numeric command ID?

I'm not following here. Where would that numeric command ID comning from?


 GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command

this is also not intended, I'm quite sure.


Going back to the OsmoHLR CTRL commands -- they are implemented in a
way that doesn't match the CTRL interface ways. Let's collapse them.

 SET enable-ps <IMSI>
 SET disable-ps <IMSI>
 SET status-ps <IMSI>

indeed, this is not proper.


 SET subscriber.by-imsi.123456789098765.ps-enabled 1
 SET subscriber.by-imsi.123456789098765.ps-enabled 0
 GET subscriber.by-imsi.123456789098765.ps-enabled

makes a lot of sense to me.


We can also expand this later to things like

 GET subscriber.by-imsi.123456789098765.status
 SET subscriber.by-imsi.123456789098765.msisdn 2345
 GET subscriber.by-msisdn.2342.status
 SET subscriber.by-msisdn.2342.ps-enabled 0
 GET subscriber.by-imei.987654321234565.imsi

looks good!


We could leave the enable-ps, disable-ps, status-ps commands in place
in case anyone is using it yet. I assume no-one is though.

I don't think we need to keep compatibility at this point.

--
- Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                 (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin>

------------------------------

Message: 5
Date: Wed, 27 Sep 2017 21:46:27 -0400
From: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
To: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
Cc: "openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>" <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
   <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com<mailto:CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

I really appreciate your quick replies.

I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it?

--
Kathryn

On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> wrote:


Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc
values.

If you could just revert that operation, there would be no [security]
advantage of card-individual OPc values over a global OP value, and
hence that entire option could be dropped from the specifications
altogether.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 27 Sep 2017 18:04:35 -0800
From: Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
Cc: openbsc <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
   <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com<mailto:CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>> wrote:

I have a USIM that I wanted to program. However, I am getting the
runtime error for exceeding the number of attempts to enter the ADM1
key. Is there any fix for it?

Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery.

But the sysmoUSIM cards sold at shop.sysmocom.de<http://shop.sysmocom.de> are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing?

If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be.

M~


------------------------------

Message: 7
Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
From: Tomcs?nyi, Domonkos <domi at tomcsanyi.net<mailto:domi at tomcsanyi.net>>
To: Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>>
Cc: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>, openbsc
   <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net<mailto:1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net>>
Content-Type: text/plain; charset="utf-8"

Hi Kathryn and Mychaela,

2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>> ?rta:

Someone please correct me if I am wrong, but I would assume that
having exceeded the number of attempts to enter the ADM1 key means
that the USIM is bricked beyond recovery.

This is my understanding as well.

Cheers,

Domi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OpenBSC mailing list
OpenBSC at lists.osmocom.org<mailto:OpenBSC at lists.osmocom.org>
https://lists.osmocom.org/mailman/listinfo/openbsc


------------------------------

End of OpenBSC Digest, Vol 35, Issue 30
***************************************



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/eb413eef/attachment.htm>

From djks74 at gmail.com  Thu Sep 28 11:49:49 2017
From: djks74 at gmail.com (Sandi Suhendro)
Date: Thu, 28 Sep 2017 18:49:49 +0700
Subject: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <308DD9881922A94187C6359714B51425BC074EAB@S900X023.kapsch.co.at>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
 <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
 <74FC000C-ACC2-445C-A53D-A3055A3AFFF1@tomcsanyi.net>
 <308DD9881922A94187C6359714B51425BC074EAB@S900X023.kapsch.co.at>
Message-ID: <CANWiJYjmAj12qd1YtZdcvzTLWXsQTeck-Cgm1tCjRoDT2Y8AsA@mail.gmail.com>

Hi Goran,
for me all is ok install from that sources,  I builded Openbsc, etc on kali
linux just 2 weeks ago from that sources.

maybe its just dependency, you need to put more info for the error and
someone will help more.

regards,
DUO

On Thu, Sep 28, 2017 at 6:34 PM, Popovic Goran <Goran.Popovic at kapsch.net>
wrote:

> Hi,
>
> Thank you very much for your response,
> This make me believe in this project, I have just found that there are
> released Nightly Builds for Osmocom GSM related software. I will
> reinstall my server with one of this builds and try everything again, Basically
> I was following procedure from Site, on my Debian server but was stucked
> with dependencies which I were not able to compile, Libosmo-sccp,
> Libosmo-netif, libosmo-abis
> *https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source*
> <https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source> I
> will come back with questions after I tried again. BR Goran
>
>
>
>
>
> *From:* Tomcs?nyi, Domonkos [mailto:domi at tomcsanyi.net]
> *Sent:* Thursday, September 28, 2017 1:07 PM
> *To:* Popovic Goran <Goran.Popovic at kapsch.net>
> *Cc:* openbsc at lists.osmocom.org
> *Subject:* Re: OpenBSC Digest, Vol 35, Issue 30
>
>
>
> Hi Goran,
>
>
>
> Without any exact details, like error messages and commands that you tried
> we cannot give you much help sadly.
>
>
>
> Please provide all details possible in text format, and I?m sure someone
> will help.
>
>
>
> Regards,
>
> Domi
>
>
> 2017. szept. 28. d?tummal, 11:18 id?pontban Popovic Goran <
> Goran.Popovic at kapsch.net> ?rta:
>
> HI,
> My name is Goran, I have femto cell would like test osmo iuh. Installed
> libosmocore on debian server, but got lot of problems with osmo IuH
> compiling. Curenlty I am stucked with osmo-sccp library.
> Also tried Vagrant IuH image, but there is issue with permisions,
> Is there a way to get some help for solving this issues,
> Thanks
> Goran
>
>
>
>
> -----Original Message-----
> From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org
> <openbsc-bounces at lists.osmocom.org>] On Behalf Of
> openbsc-request at lists.osmocom.org
> Sent: Thursday, September 28, 2017 4:36 AM
> To: openbsc at lists.osmocom.org
> Subject: OpenBSC Digest, Vol 35, Issue 30
>
> Send OpenBSC mailing list submissions to
>    openbsc at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>    openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>    openbsc-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
>   1. Re: branches in openbsc.git (Harald Welte)
>   2. Re: randomness of identifiers (Harald Welte)
>   3. Re: Retrieve OP from OPc and Ki (Harald Welte)
>   4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
>   5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
>   6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
>   7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 28 Sep 2017 07:05:09 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: branches in openbsc.git
> Message-ID: <20170927230509.pw4xug7jntrfvts2 at nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
>
> another call for anyone aware of important branches on openbsc.git to
>
> please name them, so that they can be migrated to the new repositories.
>
> But foremost, please name them, thanks!
>
>
>
> From "my" branches, I can see the following:
>
> * laforge/bssgp_fc -> osmo-sgsn
> * laforge/gprs-suspend -> osmo-bsc
> * laforge/power_control -> osmo-bsc
>
> --
> - 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)
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 28 Sep 2017 07:15:01 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: randomness of identifiers
> Message-ID: <20170927231501.zyqrali3onodi4iw at nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Neels,
>
> On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
>
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
>
> For TMSI allocation, my "cryptographic gut feeling"[tm] is that
>
> something like rand() or any other pseudo-random generator of
>
> significantly large period is sufficient *if* it is seeded by a
>
> non-predictable value.  So something like seeding with getrandom() result
> should be fine?
>
>
>
> Might also make sense to periodically re-seed from /dev/urandom /
>
> getrandom(), like every 100 TMSIs, or based on a timeout might be
>
> easier to implement.
>
>
> I would try to avoid any predictability here.  Having a fixed time
> interval would be known to an attackers.  So if he was somehow able to
> reduce/exhaust the entropy at the known time for re-seeding, it would be
> bad.
>
> Similar for "every 100 TMSIs", which is something under control of any
> attacker as he can control the number of location updates via the public
> radio interface [to some extent] and thus control the time at whcih
> re-seeding is done.
>
> Maybe I'm going overboard here, but I think if you want to re-seed, you
> want to ideally do it at a non-predictable and non-controllable point in
> time.  Like a random time interval ;)
>
>
> For long-term stable key (Ki/Op) generation for provisioning SIM
>
> cards + populating a HLR, I would certainly opt for using stronger
>
> randomness sources.  However, I don't think we actually implement
>
> that anywhere, do we?
>
>
>
> what does openssh use for public/private keypair generation?
>
>
> I'm not sure you can compare the requirements for generation of RSA
> public/private keys with those for generation of symmetric keys. You can
> find different recommendations in the literature.  But I guess that's
> mainly due to the fact that people usually assume you have long-term stable
> public/private keys and short-lived symmetric session keys.  In our case,
> it's long-lived symmetric keys.
>
> But as indicated, I think our focus is to find a proper solution for
> generation of TMSIs and for random numbers used in authentication
> challenges.  K/OPc pair generation is not supported in current Osmocom
> tools anyway, as we presume the SIM cards already have sufficiently random
> key material and those keys are entered into the HLR.
>
> 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)
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 28 Sep 2017 06:52:28 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID: <20170927225228.u4udbuhk2fyebrl5 at nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Kathryn,
>
> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
>
> Is there any way to retrieve the value of OP from OPc and Ki?
>
>
> No, that defeats the entire purpose of having card-individual OPc values.
>
> If you could just revert that operation, there would be no [security]
> advantage of card-individual OPc values over a global OP value, and hence
> that entire option could be dropped from the specifications altogether.
>
> 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)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 28 Sep 2017 06:50:03 +0800
> From: Harald Welte <laforge at gnumonks.org>
> To: Neels Hofmeyr <nhofmeyr at sysmocom.de>
> Cc: Holger Freyther <holger at freyther.de>, openbsc at lists.osmocom.org
> Subject: Re: ctrl interface: GET a variable with parameter
> Message-ID: <20170927225003.ix4qgulake4gugyu at nataraja>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Neels,
>
> On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
>
> Also we do have a concept of nesting CTRL nodes separated by dots in
>
> the variable name, looking at bsc_ctrl_node_lookup() and
> fsm_ctrl_node_lookup().
>
>
> correct.
>
>
> I notice though that we do still have open doors for a lot of nonsense
>
> being sent to it without proper validation or error messages.
>
>
>
>  GET 42 existing-variable.trailing.names.ignored more nonsense
>
> following being ignored
>
>
>
> in effect is identical to:
>
>
>
>  GET 42 existing-variable
>
>
>
> So we should probably enforce that there is no ignored nonsense...
>
>
> I agree.
>
>
> Should we also enforce a numeric command ID?
>
>
> I'm not following here. Where would that numeric command ID comning from?
>
>
>  GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
>
>
> this is also not intended, I'm quite sure.
>
>
> Going back to the OsmoHLR CTRL commands -- they are implemented in a
>
> way that doesn't match the CTRL interface ways. Let's collapse them.
>
>
>
>  SET enable-ps <IMSI>
>
>  SET disable-ps <IMSI>
>
>  SET status-ps <IMSI>
>
>
> indeed, this is not proper.
>
>
>  SET subscriber.by-imsi.123456789098765.ps-enabled 1
>
>  SET subscriber.by-imsi.123456789098765.ps-enabled 0
>
>  GET subscriber.by-imsi.123456789098765.ps-enabled
>
>
> makes a lot of sense to me.
>
>
> We can also expand this later to things like
>
>
>
>  GET subscriber.by-imsi.123456789098765.status
>
>  SET subscriber.by-imsi.123456789098765.msisdn 2345
>
>  GET subscriber.by-msisdn.2342.status
>
>  SET subscriber.by-msisdn.2342.ps-enabled 0
>
>  GET subscriber.by-imei.987654321234565.imsi
>
>
> looks good!
>
>
> We could leave the enable-ps, disable-ps, status-ps commands in place
>
> in case anyone is using it yet. I assume no-one is though.
>
>
> I don't think we need to keep compatibility 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)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/
> 20170928/d568b5f9/attachment-0001.bin>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 27 Sep 2017 21:46:27 -0400
> From: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> To: Harald Welte <laforge at gnumonks.org>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID:
>    <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I really appreciate your quick replies.
>
> I have a USIM that I wanted to program. However, I am getting the runtime
> error for exceeding the number of attempts to enter the ADM1 key. Is there
> any fix for it?
>
> --
> Kathryn
>
> On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org>
> wrote:
>
>
> Hi Kathryn,
>
>
>
> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
>
> Is there any way to retrieve the value of OP from OPc and Ki?
>
>
>
> No, that defeats the entire purpose of having card-individual OPc
>
> values.
>
>
>
> If you could just revert that operation, there would be no [security]
>
> advantage of card-individual OPc values over a global OP value, and
>
> hence that entire option could be dropped from the specifications
>
> altogether.
>
>
>
> 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)
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/
> 20170927/620a2963/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 27 Sep 2017 18:04:35 -0800
> From: Mychaela Falconia <mychaela.falconia at gmail.com>
> To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>
> Cc: openbsc <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID:
>    <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com> wrote:
>
> I have a USIM that I wanted to program. However, I am getting the
>
> runtime error for exceeding the number of attempts to enter the ADM1
>
> key. Is there any fix for it?
>
>
> Someone please correct me if I am wrong, but I would assume that having
> exceeded the number of attempts to enter the ADM1 key means that the USIM
> is bricked beyond recovery.
>
> But the sysmoUSIM cards sold at shop.sysmocom.de are fairly inexpensive
> for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy -
> or is there another dimension to this problem which I am missing?
>
> If you are anywhere near local to me (California, USA) I could give you
> one of my sysmoUSIM cards, but I am guessing it probably won't help you as
> I bought the cheaper version without the ADM1 keys - for my application
> (production testing of my GSM MS hardware) it doesn't matter what the
> programming of the (U)SIM happens to be.
>
> M~
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
> From: Tomcs?nyi, Domonkos <domi at tomcsanyi.net>
> To: Mychaela Falconia <mychaela.falconia at gmail.com>
> Cc: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com>, openbsc
>    <openbsc at lists.osmocom.org>
> Subject: Re: Retrieve OP from OPc and Ki
> Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Kathryn and Mychaela,
>
> 2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <
> mychaela.falconia at gmail.com> ?rta:
>
> Someone please correct me if I am wrong, but I would assume that
>
> having exceeded the number of attempts to enter the ADM1 key means
>
> that the USIM is bricked beyond recovery.
>
>
> This is my understanding as well.
>
> Cheers,
>
> Domi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/
> 20170928/c99fe291/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> ------------------------------
>
> End of OpenBSC Digest, Vol 35, Issue 30
> ***************************************
>
>
>
> The information contained in this e-mail message is privileged and
> confidential and is for the exclusive use of the addressee. The person who
> receives this message and who is not the addressee, one of his employees or
> an agent entitled to hand it over to the addressee, is informed that he may
> not use, disclose or reproduce the contents thereof, and is kindly asked to
> notify the sender and delete the e-mail immediately.
>
>
>
>
> The information contained in this e-mail message is privileged and
> confidential and is for the exclusive use of the addressee. The person who
> receives this message and who is not the addressee, one of his employees or
> an agent entitled to hand it over to the addressee, is informed that he may
> not use, disclose or reproduce the contents thereof, and is kindly asked to
> notify the sender and delete the e-mail immediately.
>
>


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

From Goran.Popovic at kapsch.net  Thu Sep 28 12:25:31 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Thu, 28 Sep 2017 12:25:31 +0000
Subject: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <CANWiJYjmAj12qd1YtZdcvzTLWXsQTeck-Cgm1tCjRoDT2Y8AsA@mail.gmail.com>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
 <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
 <74FC000C-ACC2-445C-A53D-A3055A3AFFF1@tomcsanyi.net>
 <308DD9881922A94187C6359714B51425BC074EAB@S900X023.kapsch.co.at>
 <CANWiJYjmAj12qd1YtZdcvzTLWXsQTeck-Cgm1tCjRoDT2Y8AsA@mail.gmail.com>
Message-ID: <308DD9881922A94187C6359714B51425BC074F60@S900X023.kapsch.co.at>

Hi thanks for suggestion,
I think all dependency are installed now.
This is output when I try to install osmo-iuh

BR
Goran


From: Sandi Suhendro [mailto:djks74 at gmail.com]
Sent: Thursday, September 28, 2017 1:50 PM
To: Popovic Goran <Goran.Popovic at kapsch.net>
Cc: Tomcs?nyi, Domonkos <domi at tomcsanyi.net>; openbsc at lists.osmocom.org
Subject: Re: OpenBSC Digest, Vol 35, Issue 30

Hi Goran,
for me all is ok install from that sources,  I builded Openbsc, etc on kali linux just 2 weeks ago from that sources.

maybe its just dependency, you need to put more info for the error and someone will help more.
regards,
DUO

On Thu, Sep 28, 2017 at 6:34 PM, Popovic Goran <Goran.Popovic at kapsch.net<mailto:Goran.Popovic at kapsch.net>> wrote:
Hi,
Thank you very much for your response,
This make me believe in this project, I have just found that there are released Nightly Builds for Osmocom GSM related software.
I will reinstall my server with one of this builds and try everything again,
Basically I was following procedure from Site, on my Debian server but was stucked with dependencies which I were not able to compile, Libosmo-sccp, Libosmo-netif, libosmo-abis
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source
I will come back with questions after I tried again.
BR
Goran






From: Tomcs?nyi, Domonkos [mailto:domi at tomcsanyi.net<mailto:domi at tomcsanyi.net>]
Sent: Thursday, September 28, 2017 1:07 PM
To: Popovic Goran <Goran.Popovic at kapsch.net<mailto:Goran.Popovic at kapsch.net>>
Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: OpenBSC Digest, Vol 35, Issue 30

Hi Goran,

Without any exact details, like error messages and commands that you tried we cannot give you much help sadly.

Please provide all details possible in text format, and I?m sure someone will help.

Regards,
Domi

2017. szept. 28. d?tummal, 11:18 id?pontban Popovic Goran <Goran.Popovic at kapsch.net<mailto:Goran.Popovic at kapsch.net>> ?rta:
HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran




-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: OpenBSC Digest, Vol 35, Issue 30

Send OpenBSC mailing list submissions to
   openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>

To subscribe or unsubscribe via the World Wide Web, visit
   https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
   openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>

You can reach the person managing the list at
   openbsc-owner at lists.osmocom.org<mailto:openbsc-owner at lists.osmocom.org>

When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."


Today's Topics:

  1. Re: branches in openbsc.git (Harald Welte)
  2. Re: randomness of identifiers (Harald Welte)
  3. Re: Retrieve OP from OPc and Ki (Harald Welte)
  4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
  5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
  6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
  7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2 at nataraja<mailto:20170927230509.pw4xug7jntrfvts2 at nataraja>>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
another call for anyone aware of important branches on openbsc.git to
please name them, so that they can be migrated to the new repositories.
But foremost, please name them, thanks!

From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc

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


------------------------------

Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw at nataraja<mailto:20170927231501.zyqrali3onodi4iw at nataraja>>
Content-Type: text/plain; charset=us-ascii

Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
For TMSI allocation, my "cryptographic gut feeling"[tm] is that
something like rand() or any other pseudo-random generator of
significantly large period is sufficient *if* it is seeded by a
non-predictable value.  So something like seeding with getrandom() result should be fine?

Might also make sense to periodically re-seed from /dev/urandom /
getrandom(), like every 100 TMSIs, or based on a timeout might be
easier to implement.

I would try to avoid any predictability here.  Having a fixed time interval would be known to an attackers.  So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.

Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time.  Like a random time interval ;)

For long-term stable key (Ki/Op) generation for provisioning SIM
cards + populating a HLR, I would certainly opt for using stronger
randomness sources.  However, I don't think we actually implement
that anywhere, do we?

what does openssh use for public/private keypair generation?

I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature.  But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys.  In our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges.  K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.

Regards,
   Harald

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


------------------------------

Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
Cc: "openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>" <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5 at nataraja<mailto:20170927225228.u4udbuhk2fyebrl5 at nataraja>>
Content-Type: text/plain; charset=us-ascii

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc values.

If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.

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


------------------------------

Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>>
Cc: Holger Freyther <holger at freyther.de<mailto:holger at freyther.de>>, openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu at nataraja<mailto:20170927225003.ix4qgulake4gugyu at nataraja>>
Content-Type: text/plain; charset="us-ascii"

Hi Neels,

On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
Also we do have a concept of nesting CTRL nodes separated by dots in
the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().

correct.

I notice though that we do still have open doors for a lot of nonsense
being sent to it without proper validation or error messages.

 GET 42 existing-variable.trailing.names.ignored more nonsense
following being ignored

in effect is identical to:

 GET 42 existing-variable

So we should probably enforce that there is no ignored nonsense...

I agree.

Should we also enforce a numeric command ID?

I'm not following here. Where would that numeric command ID comning from?

 GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command

this is also not intended, I'm quite sure.

Going back to the OsmoHLR CTRL commands -- they are implemented in a
way that doesn't match the CTRL interface ways. Let's collapse them.

 SET enable-ps <IMSI>
 SET disable-ps <IMSI>
 SET status-ps <IMSI>

indeed, this is not proper.

 SET subscriber.by-imsi.123456789098765.ps-enabled 1
 SET subscriber.by-imsi.123456789098765.ps-enabled 0
 GET subscriber.by-imsi.123456789098765.ps-enabled

makes a lot of sense to me.

We can also expand this later to things like

 GET subscriber.by-imsi.123456789098765.status
 SET subscriber.by-imsi.123456789098765.msisdn 2345
 GET subscriber.by-msisdn.2342.status
 SET subscriber.by-msisdn.2342.ps-enabled 0
 GET subscriber.by-imei.987654321234565.imsi

looks good!

We could leave the enable-ps, disable-ps, status-ps commands in place
in case anyone is using it yet. I assume no-one is though.

I don't think we need to keep compatibility at this point.

--
- Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                 (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin>

------------------------------

Message: 5
Date: Wed, 27 Sep 2017 21:46:27 -0400
From: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
To: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>
Cc: "openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>" <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
   <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com<mailto:CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

I really appreciate your quick replies.

I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it?

--
Kathryn

On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> wrote:

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
Is there any way to retrieve the value of OP from OPc and Ki?

No, that defeats the entire purpose of having card-individual OPc
values.

If you could just revert that operation, there would be no [security]
advantage of card-individual OPc values over a global OP value, and
hence that entire option could be dropped from the specifications
altogether.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 27 Sep 2017 18:04:35 -0800
From: Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>>
To: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>
Cc: openbsc <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID:
   <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com<mailto:CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A at mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>> wrote:
I have a USIM that I wanted to program. However, I am getting the
runtime error for exceeding the number of attempts to enter the ADM1
key. Is there any fix for it?

Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery.

But the sysmoUSIM cards sold at shop.sysmocom.de<http://shop.sysmocom.de> are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing?

If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be.

M~


------------------------------

Message: 7
Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST)
From: Tomcs?nyi, Domonkos <domi at tomcsanyi.net<mailto:domi at tomcsanyi.net>>
To: Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>>
Cc: Kathryn Heckman <exuberant.kathryn.heckman at gmail.com<mailto:exuberant.kathryn.heckman at gmail.com>>, openbsc
   <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net<mailto:1A1DD58D-617B-4FBE-B363-21A25EBCFA83 at tomcsanyi.net>>
Content-Type: text/plain; charset="utf-8"

Hi Kathryn and Mychaela,

2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia at gmail.com<mailto:mychaela.falconia at gmail.com>> ?rta:
Someone please correct me if I am wrong, but I would assume that
having exceeded the number of attempts to enter the ADM1 key means
that the USIM is bricked beyond recovery.

This is my understanding as well.

Cheers,

Domi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OpenBSC mailing list
OpenBSC at lists.osmocom.org<mailto:OpenBSC at lists.osmocom.org>
https://lists.osmocom.org/mailman/listinfo/openbsc


------------------------------

End of OpenBSC Digest, Vol 35, Issue 30
***************************************



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



--
best regards,
Krazy Sandi
Blue Soho Recordings
Number One Recordings



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/b1a08c84/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo_iuh_instalation
Type: application/octet-stream
Size: 13420 bytes
Desc: osmo_iuh_instalation
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/b1a08c84/attachment.obj>

From nhofmeyr at sysmocom.de  Thu Sep 28 19:05:37 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 28 Sep 2017 21:05:37 +0200
Subject: building osmo-iuh -- was: OpenBSC Digest, Vol 35, Issue 30
In-Reply-To: <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
References: <mailman.1465.1506566133.2458.openbsc@lists.osmocom.org>
 <308DD9881922A94187C6359714B51425BC074C2E@S900X023.kapsch.co.at>
Message-ID: <20170928190537.GC27314@ass40.sysmocom.de>

Hi,

first of all please pick a useful email subject when writing to a mailing
list.

Secondly, don't ever send a mailing list digest back to the mailing list.
This is seriously bad, you are re-inserting a digest into the next digest,
as well as the mail archive, as well as everyone's mail inbox.

About your questions: clean your system of any previous osmocom
installations, then best re-clone and rebuild everything from scratch. The
errors you are seeing hint at conflicting previous installations.

You may also try a top-level makefile building everything from scratch:
git://git.osmocom.org/osmo-dev (see the enclosed README file)

May I ask which femto cell you would like to test? You will have to be
able to configure it, and it needs to expose the Iuh interface for Osmocom
to work with it. You need to run:

  femto --> osmo-hnbgw --> osmo-stp --> osmo-msc --> osmo-hlr
                                                 --> osmo-bsc_mgcp

(The wiki needs updating on this)

~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/20170928/bd0d839a/attachment.bin>

From Goran.Popovic at kapsch.net  Fri Sep 29 07:09:44 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Fri, 29 Sep 2017 07:09:44 +0000
Subject: Osmo_IuH_building_problems 
Message-ID: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>

HI Neels,
Thanks for provided answers and tips.
Femto wich I plane to use is Alcatel.
My primary target is Packet core, so femto-osmohnbgw-osmosgsn(osmo-hlr)-osmoggsn. 
Alredy know this want be easy task, But I will try, I expect also problem with SIM authentication. In past I did protocol simulators in Python (Gb, S11, Gn, Gx, Gy), wich were used in production for testing.  
When I hopfuly install osmo-iuh, I wll conect femto to it and try to configure it, will sniff trafic via wireshark between and check whats happening, 
Now I will try to rebulid IuH again.
BR
Goran





The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



From Goran.Popovic at kapsch.net  Fri Sep 29 15:11:23 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Fri, 29 Sep 2017 15:11:23 +0000
Subject: Osmo_IuH_building_problems 
In-Reply-To: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
Message-ID: <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>

Hi,



I tried this time from the scratch with

git://git.osmocom.org/osmo-dev



Curently stucked with



# ------------------------------------ ##

## osmo-msc 1.0.1.138-4e7ec test suite. ##

## ------------------------------------ ##



Regression tests.



  1: smpp                                            ok

  2: sms_queue_test                                  FAILED (testsuite.at:16)

  3: msc_vlr_test_no_authen                          FAILED (testsuite.at:23)

  4: msc_vlr_test_gsm_authen                         FAILED (testsuite.at:30)

  5: msc_vlr_test_gsm_ciph                           FAILED (testsuite.at:37)

  6: msc_vlr_test_umts_authen                        FAILED (testsuite.at:44)

  7: msc_vlr_test_hlr_reject                         FAILED (testsuite.at:51)

  8: msc_vlr_test_hlr_timeout                        FAILED (testsuite.at:58)

  9: msc_vlr_test_ms_timeout                         FAILED (testsuite.at:65)

10: msc_vlr_test_reject_concurrency                 FAILED (testsuite.at:72)

11: msc_vlr_test_rest                               FAILED (testsuite.at:79)



Thanks

Goran











The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170929/265ad901/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testsuite.zip
Type: application/x-zip-compressed
Size: 59800 bytes
Desc: testsuite.zip
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170929/265ad901/attachment.bin>

From holger at freyther.de  Fri Sep 29 15:18:37 2017
From: holger at freyther.de (Holger Freyther)
Date: Fri, 29 Sep 2017 23:18:37 +0800
Subject: Osmo_IuH_building_problems 
In-Reply-To: <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
 <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
Message-ID: <BC96F8CC-8FA7-44F9-9E16-5C5C6DA9B423@freyther.de>


> On 29. Sep 2017, at 23:11, Popovic Goran <Goran.Popovic at kapsch.net> wrote:
> 
> Hi,


Hi!


>  
> I tried this time from the scratch with
> git://git.osmocom.org/osmo-dev
>  
> Curently stucked with 

I haven't looked at the test results but the pretty first idea is that you installed the Osmocom libraries in a nonstandard path and need to set LD_LIBRARY_PATH. Have you considered looking at the test failure and reason about it?


holger

From Goran.Popovic at kapsch.net  Fri Sep 29 15:27:17 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Fri, 29 Sep 2017 15:27:17 +0000
Subject: Osmo_IuH_building_problems 
In-Reply-To: <BC96F8CC-8FA7-44F9-9E16-5C5C6DA9B423@freyther.de>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
 <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
 <BC96F8CC-8FA7-44F9-9E16-5C5C6DA9B423@freyther.de>
Message-ID: <308DD9881922A94187C6359714B51425BC07580F@S900X023.kapsch.co.at>

Hi Holger,
Thanks for response,
>From tesfailure log this error is seen

+/home/popovicg/osmo-dev/make-3G+2G-default+iu/osmo-msc/tests/sms_queue/sms_queue_test: error while loading shared libraries: libsmpp34.so.0: cannot open shared object file: No such file or directory


I haven't looked at the test results but the pretty first idea is that you installed the Osmocom libraries in a nonstandard path and need to set LD_LIBRARY_PATH. Have you considered looking at the test failure and reason about it?


holger



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



From holger at freyther.de  Fri Sep 29 15:44:04 2017
From: holger at freyther.de (Holger Freyther)
Date: Fri, 29 Sep 2017 23:44:04 +0800
Subject: Osmo_IuH_building_problems 
In-Reply-To: <308DD9881922A94187C6359714B51425BC07580F@S900X023.kapsch.co.at>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
 <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
 <BC96F8CC-8FA7-44F9-9E16-5C5C6DA9B423@freyther.de>
 <308DD9881922A94187C6359714B51425BC07580F@S900X023.kapsch.co.at>
Message-ID: <34B2B610-EA59-42EC-BA7B-8A44CA04B6FE@freyther.de>


> On 29. Sep 2017, at 23:27, Popovic Goran <Goran.Popovic at kapsch.net> wrote:
> 
> Hi Holger,

Hi,


> Thanks for response,
> From tesfailure log this error is seen
> 
> +/home/popovicg/osmo-dev/make-3G+2G-default+iu/osmo-msc/tests/sms_queue/sms_queue_test: error while loading shared libraries: libsmpp34.so.0: cannot open shared object file: No such file or directory
> 

> I haven't looked at the test results but the pretty first idea is that you installed the Osmocom libraries in a nonstandard path and need to set LD_LIBRARY_PATH. Have you considered looking at the test failure and reason about it?

and a fix was already quoted. As you are doing professional work and you might not be proficient with GNU/Linux, have you considered getting professional help for you and your team at Kapsch?

holger

From Goran.Popovic at kapsch.net  Fri Sep 29 16:41:58 2017
From: Goran.Popovic at kapsch.net (Popovic Goran)
Date: Fri, 29 Sep 2017 16:41:58 +0000
Subject: Osmo_IuH_building_problems 
In-Reply-To: <34B2B610-EA59-42EC-BA7B-8A44CA04B6FE@freyther.de>
References: <308DD9881922A94187C6359714B51425BC075230@S900X023.kapsch.co.at>
 <308DD9881922A94187C6359714B51425BC0757B4@S900X023.kapsch.co.at>
 <BC96F8CC-8FA7-44F9-9E16-5C5C6DA9B423@freyther.de>
 <308DD9881922A94187C6359714B51425BC07580F@S900X023.kapsch.co.at>
 <34B2B610-EA59-42EC-BA7B-8A44CA04B6FE@freyther.de>
Message-ID: <308DD9881922A94187C6359714B51425BC0758D8@S900X023.kapsch.co.at>

Hi Holger,
Apretiate for answer.
Profesional help is not option for me because this is not done as my bussines project, this is for my pleasure, but I understand that lot of GNU/Linux answers can be found by ckecking logs and google, before raising question on mail group

Thanks 
Goran



 
 

> I haven't looked at the test results but the pretty first idea is that you installed the Osmocom libraries in a nonstandard path and need to set LD_LIBRARY_PATH. Have you considered looking at the test failure and reason about it?

and a fix was already quoted. As you are doing professional work and you might not be proficient with GNU/Linux, have you considered getting professional help for you and your team at Kapsch?

holger



The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.



From laforge at gnumonks.org  Sat Sep 30 01:39:53 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 30 Sep 2017 09:39:53 +0800
Subject: branches in openbsc.git
In-Reply-To: <da2ff43e-a1fb-0696-f73f-cfc9a5a47ad6@sysmocom.de>
References: <20170927222231.GA25140@my.box>
 <da2ff43e-a1fb-0696-f73f-cfc9a5a47ad6@sysmocom.de>
Message-ID: <20170930013953.qbwmayqogcsnc7ye@nataraja>

Hi Max,

On Thu, Sep 28, 2017 at 10:22:35AM +0200, Max wrote:
> All my branches ../max/.. can be safely removed from the openbsc repo.

it is the responsibility of the individual developer to remove his own
unneeded branches.  So please remove any unneeded branches yourself.

Neels' question was about which branches need to be migrated to the new
repositories - which according to your anwer is apparently 'none' for
max/*

-- 
- 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  Sat Sep 30 11:24:56 2017
From: msuraev at sysmocom.de (Max)
Date: Sat, 30 Sep 2017 13:24:56 +0200
Subject: branches in openbsc.git
In-Reply-To: <20170930013953.qbwmayqogcsnc7ye@nataraja>
References: <20170927222231.GA25140@my.box>
 <da2ff43e-a1fb-0696-f73f-cfc9a5a47ad6@sysmocom.de>
 <20170930013953.qbwmayqogcsnc7ye@nataraja>
Message-ID: <1d96b519-a1c7-458b-0078-8f5fc2a3e57a@sysmocom.de>

I'd love to but since migration to gerrit I'm unable to modify main repo directly. Is
there some way to do it via gerrit?

30.09.2017 03:39, Harald Welte ?????:
> it is the responsibility of the individual developer to remove his own
> unneeded branches.  So please remove any unneeded branches yourself.

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






From laforge at gnumonks.org  Sat Sep 30 11:55:02 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 30 Sep 2017 19:55:02 +0800
Subject: branches in openbsc.git
In-Reply-To: <1d96b519-a1c7-458b-0078-8f5fc2a3e57a@sysmocom.de>
References: <20170927222231.GA25140@my.box>
 <da2ff43e-a1fb-0696-f73f-cfc9a5a47ad6@sysmocom.de>
 <20170930013953.qbwmayqogcsnc7ye@nataraja>
 <1d96b519-a1c7-458b-0078-8f5fc2a3e57a@sysmocom.de>
Message-ID: <20170930115502.k574lmxjjm3hqgyb@nataraja>

On Sat, Sep 30, 2017 at 01:24:56PM +0200, Max wrote:
> I'd love to but since migration to gerrit I'm unable to modify main repo directly. Is
> there some way to do it via gerrit?

simply push to gerrit instead of the old git repo.  any branch removed in gerrit
will be removed automatically in the public master repo.

Working with branches since gerrit was introduced is exactly like before, you just
work on the 'gerrit' remote rather than the old one (probably 'origin' in most
setups).

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