From msuraev at sysmocom.de  Fri Sep  1 15:01:14 2017
From: msuraev at sysmocom.de (Max)
Date: Fri, 1 Sep 2017 17:01:14 +0200
Subject: RFC: OpenGGSN split/rename
In-Reply-To: <20170831115646.fy6rqhvyem5izjyc@nataraja>
References: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de>
 <20170831115646.fy6rqhvyem5izjyc@nataraja>
Message-ID: <0677405b-25ba-ec63-7811-4a47878bf9ad@sysmocom.de>

On 31.08.2017 13:56, Harald Welte wrote:
> Not so sure if that would really simplify it.  What would be a good idea is
> an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency
> from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support"
> behavior.

>From the point of release automation - it certainly would: right now we treat each
repo either as a library or as a non-library project. This allows us to generate
meaningful changelogs and check for things like missing API/ABI libversion bump.

Supporting both in the same repo would make helper code much more complex. AFAIK
OpenGGSN is the only Osmocom project which produces both library and non-library
packages.
> The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
> branch where the VTY is introduced.  I've almost decided against it meanwhile,
> given that > 90% of the code still is OpenGGSN code, and credit belongs to the
> creators of that and not to Osmocom.
>
> Also, from an User point-of-view, it will be a different program. All recipes, manuals,
> wiki pages, etc. will need updates.  But then, they will need updates due to the
> vty / config file changes anyway, so it might actually be better to have a new
> name since it "feels" completely different with VTY and related configuration than
> the old OpenGGSN.
I think people tend to associate program's name more with how it "feels like" to work
with it rather than who wrote it. At least I do.

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






From tom at quantonium.net  Fri Sep  1 20:32:45 2017
From: tom at quantonium.net (Tom Herbert)
Date: Fri, 1 Sep 2017 13:32:45 -0700
Subject: GTP-C v2 in open grps
Message-ID: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>

Hello,

I am a newbie in this area so please pardon me if these are dumb or
covered questions!

I am looking for a GTP stack that implements GTP-C version 2. Is this
supported in open grps or is there a plan for that? If not, what stack
(preferably open source) is recommended?

Thanks,
Tom


From laforge at gnumonks.org  Fri Sep  1 21:59:13 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 1 Sep 2017 23:59:13 +0200
Subject: GTP-C v2 in open grps
In-Reply-To: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
Message-ID: <20170901215913.e5yghaw7eiak5sgy@nataraja>

Hi Tom!

On Fri, Sep 01, 2017 at 01:32:45PM -0700, Tom Herbert wrote:
> I am a newbie in this area so please pardon me if these are dumb or
> covered questions!

no worries.

> I am looking for a GTP stack that implements GTP-C version 2. Is this
> supported in open grps or is there a plan for that? If not, what stack
> (preferably open source) is recommended?

In Osmocom we only implement GTPv0 + GTPv1 for both C(ontrol) and U(ser)
plane, as we so far have not been getting sufficient contributions to
move beyond the 2G and 3G network element implementations nad into 4G
(which is where GTPv2-C is introduced).

I'm not an expert on available GTPv2-C code out there, but I'm aware of
* an Erlang implementation that's part of ergw, see
  https://github.com/travelping/ergw/blob/master/src/gtp_v2_c.erl
  they also have a separate erlang GTP library at
  https://github.com/travelping/gtplib

* nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/
  and has also been used in OAI at
  https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0.11

* A TTCN-3 implementation published by ETSI, primarily used for their conformance
  test suite - which means it is rather complete:
  http://forge.etsi.org/websvn/listing.php?repname=LIBS.LibGtpv2C

* another TTCN-3 implementation from Ericsson which is in the process of being
  released as FOSS, preview of which can be found in the osmo-ttcn3-hacks.git
  repository.

I guess it depends on your use case or requirements whether any of that
is applicable.  Maybe you can share some more background on what you have in
mind?

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 tom at quantonium.net  Fri Sep  1 23:27:22 2017
From: tom at quantonium.net (Tom Herbert)
Date: Fri, 1 Sep 2017 16:27:22 -0700
Subject: GTP-C v2 in open grps
In-Reply-To: <20170901215913.e5yghaw7eiak5sgy@nataraja>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
 <20170901215913.e5yghaw7eiak5sgy@nataraja>
Message-ID: <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>

Hi Harald,

On Fri, Sep 1, 2017 at 2:59 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Tom!
>
> On Fri, Sep 01, 2017 at 01:32:45PM -0700, Tom Herbert wrote:
>> I am a newbie in this area so please pardon me if these are dumb or
>> covered questions!
>
> no worries.
>
>> I am looking for a GTP stack that implements GTP-C version 2. Is this
>> supported in open grps or is there a plan for that? If not, what stack
>> (preferably open source) is recommended?
>
> In Osmocom we only implement GTPv0 + GTPv1 for both C(ontrol) and U(ser)
> plane, as we so far have not been getting sufficient contributions to
> move beyond the 2G and 3G network element implementations nad into 4G
> (which is where GTPv2-C is introduced).
>
> I'm not an expert on available GTPv2-C code out there, but I'm aware of
> * an Erlang implementation that's part of ergw, see
>   https://github.com/travelping/ergw/blob/master/src/gtp_v2_c.erl
>   they also have a separate erlang GTP library at
>   https://github.com/travelping/gtplib
>
> * nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/
>   and has also been used in OAI at
>   https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0.11
>
I looked at that, it's pretty minimal for our purposed.

> * A TTCN-3 implementation published by ETSI, primarily used for their conformance
>   test suite - which means it is rather complete:
>   http://forge.etsi.org/websvn/listing.php?repname=LIBS.LibGtpv2C
>
> * another TTCN-3 implementation from Ericsson which is in the process of being
>   released as FOSS, preview of which can be found in the osmo-ttcn3-hacks.git
>   repository.
>
> I guess it depends on your use case or requirements whether any of that
> is applicable.  Maybe you can share some more background on what you have in
> mind?
>
My user requires GTPv2 (i.e. this is for 4G network). My interest here
is really to do development on the user plane, but we need a GTP-C to
at least prototype something for their network. Also, we'd like the
kernel support for GTP-U (including IPv6 which I suppose is still
outstanding).

Thanks,
Tom

> 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  1 23:29:27 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 2 Sep 2017 01:29:27 +0200
Subject: RFC: OpenGGSN split/rename
In-Reply-To: <0677405b-25ba-ec63-7811-4a47878bf9ad@sysmocom.de>
References: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de>
 <20170831115646.fy6rqhvyem5izjyc@nataraja>
 <0677405b-25ba-ec63-7811-4a47878bf9ad@sysmocom.de>
Message-ID: <20170901232927.GB2278@my.box>

On Fri, Sep 01, 2017 at 05:01:14PM +0200, Max wrote:
> On 31.08.2017 13:56, Harald Welte wrote:
> > Not so sure if that would really simplify it.  What would be a good idea is
> > an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency
> > from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support"
> > behavior.
> 
> From the point of release automation - it certainly would: right now we treat each
> repo either as a library or as a non-library project. This allows us to generate
> meaningful changelogs and check for things like missing API/ABI libversion bump.
> 
> Supporting both in the same repo would make helper code much more complex. AFAIK
> OpenGGSN is the only Osmocom project which produces both library and non-library
> packages.

* We have the osmo-hnbgw program being installed from the "library project"
  osmo-iuh (or is it a program project also installing libosmo-ranap?);
* we have the osmo-stp program coming from libosmo-sccp;
* we now have osmo-mgw.git installing both the osmo-bsc_mgcp
  program as well as libosmo-legacy-mgcp (to-be osmo-mgw and libosmo-mgcp);
* libosmocore installs osmo-auc-gen...
and I'm fairly sure we can find more mixed library/program instances.

If we really require to strictly treat git trees as *either* library *or*
program project, we would need to do a lot more splitting. It seems to me that
we unfortunately rather should have more complex helpers instead.

I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0,
so I need to look at the new release process anyway. Let me comment on that in
a separate mail. I hope that I will thus gain a better understanding of the
difference or complexity from mixing libraries with programs.
(https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release)
I still want some more tweaks to go into the new repositories before bumping,
but can review releasing now as good as any other time.

> > The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
* I assume typo: osmo-ggsn
> > branch where the VTY is introduced.  I've almost decided against it meanwhile,
> > given that > 90% of the code still is OpenGGSN code, and credit belongs to the
> > creators of that and not to Osmocom.

If we are the sole maintainers now, it makes sense to embed openggsn in our
naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We
should still credit the origins in README and/or header comments of course.

There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that
building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have
listed numerous similar instances above, so no real reason to split.

IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm
unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of
the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").

In any case, this now is an ideal time to do renames like this, while we're
busy rejiggering half the core network anyway. It will just be part of the new
way that everyone needs to adjust to.

~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/osmocom-net-gprs/attachments/20170902/43f89acb/attachment.bin>

From laforge at gnumonks.org  Sat Sep  2 08:24:17 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 2 Sep 2017 10:24:17 +0200
Subject: RFC: OpenGGSN split/rename
In-Reply-To: <20170901232927.GB2278@my.box>
References: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de>
 <20170831115646.fy6rqhvyem5izjyc@nataraja>
 <0677405b-25ba-ec63-7811-4a47878bf9ad@sysmocom.de>
 <20170901232927.GB2278@my.box>
Message-ID: <20170902082417.7vh4zuk5yyaz3gfi@nataraja>

Hi Neels,

On Sat, Sep 02, 2017 at 01:29:27AM +0200, Neels Hofmeyr wrote:
> If we really require to strictly treat git trees as *either* library *or*
> program project, we would need to do a lot more splitting. It seems to me that
> we unfortunately rather should have more complex helpers instead.

ACK.  I also don't see why users should have to deal with even more repositories
just so that the maintainer can have simpler scripts.

> I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0,
> so I need to look at the new release process anyway. Let me comment on that in
> a separate mail. I hope that I will thus gain a better understanding of the
> difference or complexity from mixing libraries with programs.
> (https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release)
> I still want some more tweaks to go into the new repositories before bumping,
> but can review releasing now as good as any other time.

You could also do a 1.99.0 before as an exercise :)

> > > The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
> * I assume typo: osmo-ggsn
> > > branch where the VTY is introduced.  I've almost decided against it meanwhile,
> > > given that > 90% of the code still is OpenGGSN code, and credit belongs to the
> > > creators of that and not to Osmocom.
> 
> If we are the sole maintainers now, it makes sense to embed openggsn in our
> naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We
> should still credit the origins in README and/or header comments of course.

Ok, then let's aim for that.

> There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that
> building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have
> listed numerous similar instances above, so no real reason to split.

I agree, no split (for now).

> IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm
> unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of
> the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").

well, we didn't reinvent the wheel where it wasn't required (such as libgtp and libsmpp34).

> In any case, this now is an ideal time to do renames like this, while we're
> busy rejiggering half the core network anyway. It will just be part of the new
> way that everyone needs to adjust to.

I would time a rename with the introduction of significant user-visible changes.

For the GGSN, this is when the VTY is introduced (ggsn binary to
osmo-ggsn, which is already in a branch and could be merged any day.

For libgtp, I would time this with introducing all the API/ABI breakage needed
for maintaining pdp contexts per GSN and for supporting IPv6 transport
layer addresses. This has currently not been a priority, though :/

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  2 08:29:52 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 2 Sep 2017 10:29:52 +0200
Subject: GTP-C v2 in open grps
In-Reply-To: <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
 <20170901215913.e5yghaw7eiak5sgy@nataraja>
 <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>
Message-ID: <20170902082952.naa2psqjig4v6hr4@nataraja>

Hi Tom,

On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
> > * nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/
> >   and has also been used in OAI at
> >   https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0.11
> >
> I looked at that, it's pretty minimal for our purposed.

Welcom to the (cellular) telecom world.  Feels like the state of Linux in the 
mid-1990ies:  Some minimal FOSS implementations exist, but most of the work still
has to be done.  We've been trying hard since 2008 inside Osmocom, but as indicated
so far no 4G related contributions (financially or in terms of code).

> My user requires GTPv2 (i.e. this is for 4G network). My interest here
> is really to do development on the user plane, 

Are we talking about FOSS development here?

> but we need a GTP-C to at least prototype something for their network.

What exactly do you want to prototype? Which of the many GTPv2-C
transactions do you need?  I guess if you can deal e.g. without
relocation, then the complexity is quite reduced.

> Also, we'd like the kernel support for GTP-U (including IPv6 which I
> suppose is still outstanding).

correct.  We've just added user-plane IPv6 support to openggsn in
userspace, v6 user plane (or even transport plane) in kernel GTP is
still another area looking for contributions.

-- 
- 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 tom at quantonium.net  Sat Sep  2 16:51:57 2017
From: tom at quantonium.net (Tom Herbert)
Date: Sat, 2 Sep 2017 09:51:57 -0700
Subject: GTP-C v2 in open grps
In-Reply-To: <20170902082952.naa2psqjig4v6hr4@nataraja>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
 <20170901215913.e5yghaw7eiak5sgy@nataraja>
 <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>
 <20170902082952.naa2psqjig4v6hr4@nataraja>
Message-ID: <CAPDqMerzHJe3bZtj53ozODu3zQ5k6DfXzneSLARPzDBvJm6qww@mail.gmail.com>

On Sat, Sep 2, 2017 at 1:29 AM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Tom,
>
> On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
>> > * nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/
>> >   and has also been used in OAI at
>> >   https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0.11
>> >
>> I looked at that, it's pretty minimal for our purposed.
>
> Welcom to the (cellular) telecom world.  Feels like the state of Linux in the
> mid-1990ies:  Some minimal FOSS implementations exist, but most of the work still
> has to be done.  We've been trying hard since 2008 inside Osmocom, but as indicated
> so far no 4G related contributions (financially or in terms of code).
>
>> My user requires GTPv2 (i.e. this is for 4G network). My interest here
>> is really to do development on the user plane,
>
> Are we talking about FOSS development here?
>
Yes.

>> but we need a GTP-C to at least prototype something for their network.
>
> What exactly do you want to prototype? Which of the many GTPv2-C
> transactions do you need?  I guess if you can deal e.g. without
> relocation, then the complexity is quite reduced.
>
I need the control plane to be able to develop the data path. The
ultimate goal of our project is to an implement and ILA data path;
that is use it instead of GTP-U tunneling but still have the GTP-C
control plane. The support we need starts out simple, just create a
data path and demonstrate the benefits (maybe as much that is in
nwgtpv2). As we proceed, obviously we'll want to prototype more of the
capabilities such as handover. That being said, this is just a
prototype for now!

How much effort do you think it would be to implement GTPv2-C?

>> Also, we'd like the kernel support for GTP-U (including IPv6 which I
>> suppose is still outstanding).
>
> correct.  We've just added user-plane IPv6 support to openggsn in
> userspace, v6 user plane (or even transport plane) in kernel GTP is
> still another area looking for contributions.
>
What is the difference between user plane and transport plane?

I'm looking at the GTP kernel code, it seems to be pretty
straightforward to add IPv6, and the common offloads and I could look
at that once I figure out a solution for using GTP-C v2.

Thanks,
Tom

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


From nhofmeyr at sysmocom.de  Sat Sep  2 23:07:59 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 3 Sep 2017 01:07:59 +0200
Subject: RFC: OpenGGSN split/rename
In-Reply-To: <20170902082417.7vh4zuk5yyaz3gfi@nataraja>
References: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de>
 <20170831115646.fy6rqhvyem5izjyc@nataraja>
 <0677405b-25ba-ec63-7811-4a47878bf9ad@sysmocom.de>
 <20170901232927.GB2278@my.box>
 <20170902082417.7vh4zuk5yyaz3gfi@nataraja>
Message-ID: <20170902230759.GA15743@my.box>

On Sat, Sep 02, 2017 at 10:24:17AM +0200, Harald Welte wrote:
> You could also do a 1.99.0 before as an exercise :)

yep, 1.inf.0 :)

> I would time a rename with the introduction of significant user-visible changes.
> 
> For the GGSN, this is when the VTY is introduced (ggsn binary to
> osmo-ggsn, which is already in a branch and could be merged any day.
> 
> For libgtp, I would time this with introducing all the API/ABI breakage needed
> for maintaining pdp contexts per GSN and for supporting IPv6 transport
> layer addresses. This has currently not been a priority, though :/

Sounds sane to me. So osmo-ggsn soonish, libosmo-gtp probably some other time.

It still does make sense to me to time the osmo-ggsn change within our switch
towards the new repositories and AoIP world, so that users get the new way in
one go. Meaning let's announce openbsc.git as legacy after that rename.

~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/osmocom-net-gprs/attachments/20170903/bc075678/attachment.bin>

From aschultz at tpip.net  Mon Sep  4 09:57:22 2017
From: aschultz at tpip.net (Andreas Schultz)
Date: Mon, 4 Sep 2017 11:57:22 +0200 (CEST)
Subject: GTP-C v2 in open grps
In-Reply-To: <CAPDqMerzHJe3bZtj53ozODu3zQ5k6DfXzneSLARPzDBvJm6qww@mail.gmail.com>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
 <20170901215913.e5yghaw7eiak5sgy@nataraja>
 <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>
 <20170902082952.naa2psqjig4v6hr4@nataraja>
 <CAPDqMerzHJe3bZtj53ozODu3zQ5k6DfXzneSLARPzDBvJm6qww@mail.gmail.com>
Message-ID: <1671267850.476820.1504519042493.JavaMail.zimbra@tpip.net>

Hi Tom,

----- On Sep 2, 2017, at 6:51 PM, Tom Herbert tom at quantonium.net wrote:

> On Sat, Sep 2, 2017 at 1:29 AM, Harald Welte <laforge at gnumonks.org> wrote:
>> Hi Tom,
>>
>> On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
>>> > * nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/
>>> >   and has also been used in OAI at
>>> >   https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0.11
>>> >
>>> I looked at that, it's pretty minimal for our purposed.
>>
>> Welcom to the (cellular) telecom world.  Feels like the state of Linux in the
>> mid-1990ies:  Some minimal FOSS implementations exist, but most of the work
>> still
>> has to be done.  We've been trying hard since 2008 inside Osmocom, but as
>> indicated
>> so far no 4G related contributions (financially or in terms of code).
>>
>>> My user requires GTPv2 (i.e. this is for 4G network). My interest here
>>> is really to do development on the user plane,
>>
>> Are we talking about FOSS development here?
>>
> Yes.
> 
>>> but we need a GTP-C to at least prototype something for their network.
>>
>> What exactly do you want to prototype? Which of the many GTPv2-C
>> transactions do you need?  I guess if you can deal e.g. without
>> relocation, then the complexity is quite reduced.
>>
> I need the control plane to be able to develop the data path. The
> ultimate goal of our project is to an implement and ILA data path;
> that is use it instead of GTP-U tunneling but still have the GTP-C
> control plane. The support we need starts out simple, just create a
> data path and demonstrate the benefits (maybe as much that is in
> nwgtpv2). As we proceed, obviously we'll want to prototype more of the
> capabilities such as handover. That being said, this is just a
> prototype for now!

GTPv2 control plane including GGSN/PGW handover works in erGW [1].
A more ready to run packaged solution it at [2].
It does support the kernel module for the data path and I would be
willing to help with getting a GGSN/PGW up and running, and implement
the IPv6 support in the control path (Erlang world).

I don't have the time right now to get into the data path implementation.

> How much effort do you think it would be to implement GTPv2-C?

As always, the problems are in the details and they are not obvious
from reading the specification.
 
>>> Also, we'd like the kernel support for GTP-U (including IPv6 which I
>>> suppose is still outstanding).
>>
>> correct.  We've just added user-plane IPv6 support to openggsn in
>> userspace, v6 user plane (or even transport plane) in kernel GTP is
>> still another area looking for contributions.
>>
> What is the difference between user plane and transport plane?

Control plane of GTPv2, data/transport plane is GTPv1. There is
no GTPv2 for the data/transport plane.
 
> I'm looking at the GTP kernel code, it seems to be pretty
> straightforward to add IPv6, and the common offloads and I could look
> at that once I figure out a solution for using GTP-C v2.

The tricky parts might be the handling to IPv6 address delegations. But
I haven't really looked at it, yet.

Regards
Andreas

[1]: https://github.com/travelping/ergw
[2]: https://github.com/travelping/ergw-gtp-c-node


From laforge at gnumonks.org  Mon Sep  4 10:30:31 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 4 Sep 2017 12:30:31 +0200
Subject: GTP-C v2 in open grps
In-Reply-To: <1671267850.476820.1504519042493.JavaMail.zimbra@tpip.net>
References: <CAPDqMepsizgxBdgawwRB_VqLt+sPJ0S1e3p4_m7+Nr+2vatvQA@mail.gmail.com>
 <20170901215913.e5yghaw7eiak5sgy@nataraja>
 <CAPDqMepAiahmO95xGV67Pzj0JMUJaTLD7Qz9bSBPrtsCn3KxHQ@mail.gmail.com>
 <20170902082952.naa2psqjig4v6hr4@nataraja>
 <CAPDqMerzHJe3bZtj53ozODu3zQ5k6DfXzneSLARPzDBvJm6qww@mail.gmail.com>
 <1671267850.476820.1504519042493.JavaMail.zimbra@tpip.net>
Message-ID: <20170904103031.dws7no42ndvmk43o@nataraja>

Hi Andreas and Tom,

On Mon, Sep 04, 2017 at 11:57:22AM +0200, Andreas Schultz wrote:
> >> correct.  We've just added user-plane IPv6 support to openggsn in
> >> userspace, v6 user plane (or even transport plane) in kernel GTP is
> >> still another area looking for contributions.
> >>
> > What is the difference between user plane and transport plane?
> 
> Control plane of GTPv2, data/transport plane is GTPv1. There is
> no GTPv2 for the data/transport plane.

Sorry, this is a misunderstanding, there are two orthogonal concepts:
* control plane is GTPv2-C
* user plane is GTPv1-U

But then, the user plane has two layers:
1) outer (transport) layer, i.e. IP addresses of the outer IP packet
2) inner (user) layer, i.e. the IP addresses of the inner IP packet

So my comment was referring to the fact that those latter two are
treated separately. Current OpenGGSN is now capable of doing IPv6 on
the inner (user) IP layer, but not on the outer (transport) layer.

> > I'm looking at the GTP kernel code, it seems to be pretty
> > straightforward to add IPv6, and the common offloads and I could look
> > at that once I figure out a solution for using GTP-C v2.
> 
> The tricky parts might be the handling to IPv6 address delegations. But
> I haven't really looked at it, yet.

Yes, this is rather hairy, you can see my recent implementatin on
OpenGGSN.  It's a complete mix of modified stateless auto-configuration
combined with 3GPP specific signaling in terms of PCO (protocol config
options).

-- 
- 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 10:04:28 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Sep 2017 12:04:28 +0200
Subject: OsmoGGSN succeeds OpenGGSN!
Message-ID: <20170906100428.gwbd5trvlk7a4agu@nataraja>

Hi all,

12 years after OpenGGSN was seemingly abandoned by its original creators,
and 7 years after Osmocom adopted it, it is time for a significant change:

OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN.

We had already taken some baby-steps in the past by introduction of a
CTRL interface as well as the use of libosmocore logging.  However, my
recent patches introducing a VTY interface and changing the
configuration file format from the 'gengetopt' style to libosmovty based
change the look+feel of the program significantly that it is a good
point to rename.

After all, if command-line arguments and config file syntax are
changing, documentation will also need to change and it becomes
confusing to users to understand that depending on the version the
documentation is correct or incorrect.

So from today on,
* osmo-ggsn is available from http://git.osmocom.org/osmo-ggsn/
* osmocom:nightly packages will build both openggsn + osmo-ggsn
* osmocom:nitb-split:nightly packages will only build osmo-ggsn
* redmine still at http://osmocom.org/projects/openggsn due to
  permanent redmine project naming...

The introduction of the VTY interface comes with many new possibilities,
such as
* multiple GGSN instances bound to different GTP IP addresses
* multiple APNs within each GGSN, each with different Address Pools and
  tun-devices
* sophisticated logging configuration (syslog, file, stdout, telnet)

What's still missing:
* re-integrate kernel GTP-U support
* create OsmoGGSN user manual in osmo-gsm-manuals.git
* migrate TTCN-3 test execution on jenkins to osmo-ggsn
* perl/python script to convert old config file to new config file
  format (any volunteers?)

Roadmap:
* IPv6 transport plane support (outer IP layer surrounding GTP/UDP)
* improved logging (ensure context is always included)
* libgtp: migration of kernel GTP-U support into libgtp (not just ggsn)
* libgtp: make PDP context hash table part of the 'gsn' structure
* once all expected ABI/API changes are done, rename libgtp to
  libosmo-gtp

In terms of maintenance, I don't want to continue to maintain OpenGGSN
for much longer.  We'll keep it around for some time and merge important
security and/or bug fixes, but I won't accept new feature patches into
OpenGGSN.

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  Wed Sep  6 13:33:24 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Sep 2017 15:33:24 +0200
Subject: OsmoGGSN succeeds OpenGGSN!
In-Reply-To: <20170906100428.gwbd5trvlk7a4agu@nataraja>
References: <20170906100428.gwbd5trvlk7a4agu@nataraja>
Message-ID: <20170906133323.GA3245@my.box>

On Wed, Sep 06, 2017 at 12:04:28PM +0200, Harald Welte wrote:
> 12 years after OpenGGSN was seemingly abandoned by its original creators,
> and 7 years after Osmocom adopted it, it is time for a significant change:
> 
> OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN.

Great! Wasn't expecting it this soon :)

> * redmine still at http://osmocom.org/projects/openggsn due to
>   permanent redmine project naming...

I wonder, when I rename a redmine wiki page, redmine offers me to redirect the
old name to the new. Doesn't that work on project level as well? Anyway, the
URL is hardly noticeable after klicking "OsmoGSSN" on the projects list.

~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/osmocom-net-gprs/attachments/20170906/2f56119b/attachment.bin>

From laforge at gnumonks.org  Wed Sep  6 13:46:22 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Sep 2017 15:46:22 +0200
Subject: OsmoGGSN succeeds OpenGGSN!
In-Reply-To: <20170906133323.GA3245@my.box>
References: <20170906100428.gwbd5trvlk7a4agu@nataraja>
 <20170906133323.GA3245@my.box>
Message-ID: <20170906134622.c7fftmbgtizh32zn@nataraja>

Hi Neels,

On Wed, Sep 06, 2017 at 03:33:24PM +0200, Neels Hofmeyr wrote:

> > * redmine still at http://osmocom.org/projects/openggsn due to
> >   permanent redmine project naming...
> 
> I wonder, when I rename a redmine wiki page, redmine offers me to redirect the
> old name to the new. Doesn't that work on project level as well? 

no. There's a project-aliases plugin, but not for redmine 3.2 :(

> Anyway, the URL is hardly noticeable after klicking "OsmoGSSN" on the projects list.

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 ravi.tandon1982 at gmail.com  Wed Sep 13 15:15:09 2017
From: ravi.tandon1982 at gmail.com (Ravi Tandon)
Date: Wed, 13 Sep 2017 17:15:09 +0200
Subject: Unable to start osmo-ggsn with -g or --gtp-linux options
Message-ID: <CAKDHAW_vr0rK0Tpa7t_5pthuf+Vrkg+p0=rm1G_j9a7N23f07A@mail.gmail.com>

Hello,

I compiled osmo-ggsn and was trying to run it as per the instructions
present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP

But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says
invalid option.
Please let me know how to start it using gtp kernel.

I have modprobed gtp.ko successfully.

[root at localhost osmo-ggsn]# lsmod |grep gtp
gtp                    28672  0
ip6_udp_tunnel         16384  1 gtp
udp_tunnel             16384  1 gtp


[root at localhost examples]# osmo-ggsn --gtp-linux -c osmo-ggsn.cfg -d
*osmo-ggsn: unrecognized option '--gtp-linux'*
<0002> ggsn.c:159 APN(internet): Starting
<0002> ggsn.c:162 APN(internet): Opening TUN device tun4
<0002> ggsn.c:167 APN(internet): Opened TUN device tun4
<0002> ggsn.c:178 APN(internet): Setting tun IP address 176.16.222.0/24
<0002> ggsn.c:224 APN(internet): Creating IPv4 pool 176.16.222.0/24
<0002> ggsn.c:245 APN(internet): Successfully started
<0002> ggsn.c:159 APN(inet6): Starting
<0002> ggsn.c:162 APN(inet6): Opening TUN device tun6
<0002> ggsn.c:167 APN(inet6): Opened TUN device tun6
<0002> ggsn.c:190 APN(inet6): Setting tun IPv6 address 2001:780:44:2000::/56
<0002> ggsn.c:236 APN(inet6): Creating IPv6 pool 2001:780:44:2000::/56
<0002> ggsn.c:245 APN(inet6): Successfully started
<0002> ggsn.c:159 APN(inet46): Starting
<0002> ggsn.c:162 APN(inet46): Opening TUN device tun46
<0002> ggsn.c:167 APN(inet46): Opened TUN device tun46
<0002> ggsn.c:178 APN(inet46): Setting tun IP address 176.16.46.0/24
<0002> ggsn.c:190 APN(inet46): Setting tun IPv6 address
2001:780:44:2100::/56
<0002> ggsn.c:224 APN(inet46): Creating IPv4 pool 176.16.46.0/24
<0002> ggsn.c:236 APN(inet46): Creating IPv6 pool 2001:780:44:2100::/56
<0002> ggsn.c:245 APN(inet46): Successfully started
<0002> ggsn.c:687 GGSN(ggsn0): Starting GGSN
<000d> gtp.c:705 GTP: gtp_newgsn() started at 192.168.11.128
<0002> ggsn.c:724 GGSN(ggsn0): Successfully started
<0005> telnet_interface.c:102 telnet at 127.0.0.1 4260
<000c> control_if.c:788 CTRL at 127.0.0.1 4257


Also, I tried executing gtp-tunnel list but it gives empty output.

[root at localhost tools]# ./gtp-tunnel list
[root at localhost tools]#

Please help.

Thanks,
Ravi
<https://osmocom.org/projects/openggsn/wiki/Kernel_GTP>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170913/c5a9eb83/attachment.htm>

From laforge at gnumonks.org  Thu Sep 14 01:36:29 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 14 Sep 2017 03:36:29 +0200
Subject: Unable to start osmo-ggsn with -g or --gtp-linux options
In-Reply-To: <CAKDHAW_vr0rK0Tpa7t_5pthuf+Vrkg+p0=rm1G_j9a7N23f07A@mail.gmail.com>
References: <CAKDHAW_vr0rK0Tpa7t_5pthuf+Vrkg+p0=rm1G_j9a7N23f07A@mail.gmail.com>
Message-ID: <20170914013629.akr6c34xg2tivotj@nataraja>

Hi Ravi,

On Wed, Sep 13, 2017 at 05:15:09PM +0200, Ravi Tandon wrote:
> I compiled osmo-ggsn and was trying to run it as per the instructions
> present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP
> 
> But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says
> invalid option.
> Please let me know how to start it using gtp kernel.

Pleae see https://osmocom.org/issues/2493

The recent conersion from OpenGGSN to OsmoGGSN has resulted in a temporary
removal of kernel GTP support.  I don't know when I'll have time to work on
this, help is of course always welcome.

Meanwhile, you will have to use OpenGGSN when you need kernel GTP support.

-- 
- 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 firatssonmez at gmail.com  Mon Sep 18 11:56:44 2017
From: firatssonmez at gmail.com (=?UTF-8?B?ZsSxcmF0IHPDtm5tZXo=?=)
Date: Mon, 18 Sep 2017 14:56:44 +0300
Subject: Update and Question
Message-ID: <CAA5f=Pg0s5fSt6sLRWHD78j7BVqR0uH8Vsr-bdxFJ+HdLxn3qQ@mail.gmail.com>

Hi,

I want to ask two questions.

I dont know if you remember, but I have been trying to backport GTP to 3.18
kernel. I fixed all the errors, it works. However there is one issue that
I'm not sure how to implement it correctly.

--->There is one private flag called IFF_NO_QUEUE and it has no
implemetation in 3.18 kernel, I just set it to an unused bit in the private
flag field. I would like to get your opinion on this.

*include/linux/netdevice.h ->(*@IFF_NO_QUEUE: device can run without qdisc
attached*)

The other thing I would like to ask is that I cannot reach the git
repository for libgtpnl. Could you please check it?

Thanks,
F?rat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170918/77b4889e/attachment.htm>

From lokira at sina.com  Tue Sep 19 06:43:09 2017
From: lokira at sina.com (lokira)
Date: Tue, 19 Sep 2017 14:43:09 +0800
Subject: Unable to access git repository
Message-ID: <20170919064309.07870C800A9@webmail.sinamail.sina.com.cn>

Hello,
I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error :
remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502
I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'.
Is my url to git repository wrong ? 

Thanks,
WangSS

From holger at freyther.de  Tue Sep 19 07:09:04 2017
From: holger at freyther.de (Holger Freyther)
Date: Tue, 19 Sep 2017 15:09:04 +0800
Subject: Unable to access git repository
In-Reply-To: <20170919064309.07870C800A9@webmail.sinamail.sina.com.cn>
References: <20170919064309.07870C800A9@webmail.sinamail.sina.com.cn>
Message-ID: <260A86E5-0F04-4E19-8924-1C0CB2BD8097@freyther.de>


> On 19. Sep 2017, at 14:43, lokira <lokira at sina.com> wrote:
> 
> Hello,


Hi!

> I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error :
> remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502
> I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'.
> Is my url to git repository wrong ? 


our cgit config listed the repo twice and apparently this leads to an error like this. Sorry about it and it is fixed now.


holger

From lokira at sina.com  Tue Sep 19 08:02:34 2017
From: lokira at sina.com (lokira)
Date: Tue, 19 Sep 2017 16:02:34 +0800
Subject: =?GBK?B?u9i4tKO6UmU6IFVuYWJsZSB0byBhY2Nlc3MgZ2l0IHJlcG9zaXRvcnk=?=
Message-ID: <20170919080234.A6295C800A9@webmail.sinamail.sina.com.cn>

Hi Holger,
It's working now!Thanks for the quick fix!

Regards,
WangSS

From laforge at gnumonks.org  Tue Sep 19 12:55:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 19 Sep 2017 20:55:04 +0800
Subject: Kernel patchset for IPv6 support on netdev mailinglist
Message-ID: <20170919125504.f6uj45o7cfxbeh4e@nataraja>

Hi all!

Just in case anyone here is intrerested, I'd like to point out that
a recent patch series for IPv6 (and other feature) support of the Linux
kernel GTP-U code has been posted to the linux-netdev list and is under
review/discussion there:
	https://www.spinics.net/lists/netdev/msg455286.html

Please follow-up with any review comments there. Thanks!

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


From nhofmeyr at sysmocom.de  Wed 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/osmocom-net-gprs/attachments/20170920/ab25ba2a/attachment.bin>

From holger at freyther.de  Thu Sep 21 03:22:34 2017
From: holger at freyther.de (Holger Freyther)
Date: Thu, 21 Sep 2017 11:22:34 +0800
Subject: Current osmo-pcu patch set
Message-ID: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>

Hi,

I am a bit lost with the review of the current osmo-pcu patchset. Going through
the patches I have difficulties to see the red thread and what is better after
we integrate the changes.

I guess the goal is to add the allocation of multiple uplink timeslots but from
my point of view this is buried in a lot of subjective sideway development. My
wish would be:


For multiple slot UL allocation:

Make the most direct patchset to implement this feature. I understand that to
avoid code duplication some methods can be re-used but instead of having 10
patches that change int->bool, change signatures of functions, maybe make it
minimal to see how it works first?

After it works send a cover mail that explains what and why you took the
approach, what the _speed_ improvement for browsing is or when it is being
used. What you see the danger in terms of common ts and allocation.



For the clean-ups:

I don't say we shouldn't do them but we should do them in a way they don't
take much time to review and still provide a net gain to the contributor.
A "cosmetic" patch that breaks the build is very suspicious and forces a
reviewer to look extra carefully into these "clean-ups".



int->bool:

I think int->bool and 1->true adds little value for an application but if
it is important then please do it by semantic patching so they can be easily
reviewed.




bts->trx:

I think there is little value to change a function signature from getting
a BTS to a TRX when the implementation starts to do:

	- bts->list
	+ trx->bts->list





"API" documentation:

Comments can be helpful and it is good to explain on a high level what a
function will do and what the side-effects will be. But in an application
I think writing:

	\param[in,out] bts Pointer to BTS struct

adds not enough value. First it is wrong as the type is not "BTS" but it
is the "C" gprs_rlcmac_bts. And second doxygen will perfectly tell you the
type of of the parameter anyway.

Documenting that -1 of a parameter has a specific semantic can have some
advantage but the risk of code/doc not agreeing is there as well.


libosmocore:

We do have a desire for reuse but everytime you make osmo-pcu depend on a
unreleased version of libosmocore rebuilding osmo-pcu get's more difficult
and the compile error is not obvious. It is not clear where the macro is
coming from. So please keep this in mind and try to find a balance.


thank you for your consideration


	holger




From msuraev at sysmocom.de  Thu Sep 21 11:14:39 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 21 Sep 2017 13:14:39 +0200
Subject: Current osmo-pcu patch set
In-Reply-To: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>
References: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>
Message-ID: <edf65b4f-a48b-0ebe-470a-346d03df9ac4@sysmocom.de>

Hi.

Thank you for your feedback and efforts in patch review.

On 21.09.2017 05:22, Holger Freyther wrote:
> I am a bit lost with the review of the current osmo-pcu patchset. Going through
> the patches I have difficulties to see the red thread and what is better after
> we integrate the changes.

It might make sense to review the ticket mentioned in commit message when reviewing
commits. It'll remove the need in guessing most of the time.

> I guess the goal is to add the allocation of multiple uplink timeslots but from
> my point of view this is buried in a lot of subjective sideway development.

It is rather big development which is also interspersed with other unrelated tasks I
work on. That's why instead of submitting huge patch bomb I'm sending partially
completed work the moment it reaches some milestone: the set of patches which I think
is ready for review. That way we increase the chance of more thorough review and it
allows to incorporate feedback early on: it's easier to change 2 recent patches than
to apply changes to patch #2 in a series of 22 patches for example.

>  My wish would be:
>
>
> For multiple slot UL allocation:
>
> Make the most direct patchset to implement this feature. I understand that to
> avoid code duplication some methods can be re-used but instead of having 10
> patches that change int->bool, change signatures of functions, maybe make it
> minimal to see how it works first?

I wholeheartedly agree but unfortunately I have troubles understanding and following
undocumented and unformatted code with 5 nested for(); in it. That's why the first
step was to unwind this code into smaller chunks, understand and document them, and
to make further changes on top of that.

> After it works send a cover mail that explains what and why you took the
> approach, what the _speed_ improvement for browsing is or when it is being
> used.

I'll certainly do that but I still think that it's worth it to get the feedback early
on, even if the code is not ready for browser testing yet. Hence the current patch
submission.

>  What you see the danger in terms of common ts and allocation.

Could you please elaborate? I'm not following.

> int->bool:
>
> I think int->bool and 1->true adds little value for an application but if
> it is important then please do it by semantic patching so they can be easily
> reviewed.

Could you please point me to an example of such patch in one of the Osmocom projects?
Would be nice to have it as a guideline/blueprint of how it should be done. Also, do
we have a wiki page which explains it? It would be helpful to know how it could make
my life as a reviewer easier too.

> bts->trx:
>
> I think there is little value to change a function signature from getting
> a BTS to a TRX when the implementation starts to do:
>
> 	- bts->list
> 	+ trx->bts->list

That's not part of the patchset in question (if I guessed correctly and you mean TS
alloc related work). The list of related changes could be found in "Related Changes"
menu in gerrit web UI.

> "API" documentation:
>
> Comments can be helpful and it is good to explain on a high level what a
> function will do and what the side-effects will be. But in an application
> I think writing:
>
> 	\param[in,out] bts Pointer to BTS struct
>
> adds not enough value. First it is wrong as the type is not "BTS" but it
> is the "C" gprs_rlcmac_bts.

It would be more helpful if this sort of feedback would be provided via gerrit
because there it's easy to point to particular line of code. That way we can be sure
that such oversights are quickly corrected. Thank you.

>  And second doxygen will perfectly tell you the
> type of of the parameter anyway.

Could you please provide a better doxygen line as an example? How would you document
it to make it more useful?

> Documenting that -1 of a parameter has a specific semantic can have some
> advantage but the risk of code/doc not agreeing is there as well.

Well, yes. There's always a risk that code will disagree with the docs. What exactly
do you propose to do to mitigate it?

> libosmocore:
>
> We do have a desire for reuse but everytime you make osmo-pcu depend on a
> unreleased version of libosmocore rebuilding osmo-pcu get's more difficult
> and the compile error is not obvious.

I think this is generic issue unrelated to OsmoPCU or libosmocore. There are some
attempts to rectify it in
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release as well
as in this ML. Don't hesitate to contribute your ideas on what the right balance
should be and how the concrete procedures should look like to the wiki.

Thank you again for taking time to make a review and for sharing it.

-- 
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 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/osmocom-net-gprs/attachments/20170921/485cb8c9/attachment.bin>

From laforge at gnumonks.org  Sat Sep 23 04:47:45 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 23 Sep 2017 12:47:45 +0800
Subject: Semantic Patching (was Re: Current osmo-pcu patch set)
In-Reply-To: <edf65b4f-a48b-0ebe-470a-346d03df9ac4@sysmocom.de>
References: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>
 <edf65b4f-a48b-0ebe-470a-346d03df9ac4@sysmocom.de>
Message-ID: <20170923044744.n6f35ayiuugsikb6@nataraja>

Hi Max,

On Thu, Sep 21, 2017 at 01:14:39PM +0200, Max wrote:
> > I think int->bool and 1->true adds little value for an application but if
> > it is important then please do it by semantic patching so they can be easily
> > reviewed.
> 
> Could you please point me to an example of such patch in one of the Osmocom projects?

http://cgit.osmocom.org/osmo-trx/commit/?id=e210f1a864b0752f5baeb14de8ddcfc7320007a4

> Would be nice to have it as a guideline/blueprint of how it should be done. Also, do
> we have a wiki page which explains it?

http://coccinelle.lip6.fr/sp.php - no sure if we want to replicate that in the osmocom wiki.

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


From nhofmeyr at sysmocom.de  Sun Sep 24 23:44:32 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 25 Sep 2017 01:44:32 +0200
Subject: Semantic Patching (was Re: Current osmo-pcu patch set)
In-Reply-To: <20170923044744.n6f35ayiuugsikb6@nataraja>
References: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>
 <edf65b4f-a48b-0ebe-470a-346d03df9ac4@sysmocom.de>
 <20170923044744.n6f35ayiuugsikb6@nataraja>
Message-ID: <20170924234432.GA5177@my.box>

> > > I think int->bool and 1->true adds little value for an application but if
> > > it is important then please do it by semantic patching so they can be easily
> > > reviewed.
> > 
> > Could you please point me to an example of such patch in one of the Osmocom projects?
> 
> http://cgit.osmocom.org/osmo-trx/commit/?id=e210f1a864b0752f5baeb14de8ddcfc7320007a4

Nice, actually, I should use that more often myself...

~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/osmocom-net-gprs/attachments/20170925/71189e67/attachment.bin>

From msuraev at sysmocom.de  Thu Sep 28 12:31:24 2017
From: msuraev at sysmocom.de (Max)
Date: Thu, 28 Sep 2017 14:31:24 +0200
Subject: Semantic Patching (was Re: Current osmo-pcu patch set)
In-Reply-To: <20170923044744.n6f35ayiuugsikb6@nataraja>
References: <4D2D6D09-964E-44F5-B3B1-12452C698500@freyther.de>
 <edf65b4f-a48b-0ebe-470a-346d03df9ac4@sysmocom.de>
 <20170923044744.n6f35ayiuugsikb6@nataraja>
Message-ID: <394450b8-e308-53c9-e740-ffde58f50b29@sysmocom.de>

Thank you for the links - I went over docs, related tutorials etc. It's a great tool
indeed but it's a tool for C.

OsmoPCU is written in C++ which is supported in spatch only at rudimentary level.
Moreover, the OsmoPCU code actively mixes C and C++. All-in-all I did not managed to
find a way to apply changes both to headers and the code at the same time.

For example, attached semantic patch properly updates all the invocations on
alloc_algorithm*() but not the definitions so the result is uncompilable.

So the question is, how shall I proceed with spatch?
- apply what's possible and do the rest manually?
- don't use it at all for c++?

Of course it might as well be the case that the patch is wrong or that I'm calling
spatch in a wrong way:
spatch --c++ --dir src -I src --sp-file alloc.spatch --in-place --recursive-includes

Ideas, opinions are greatly appreciated.

On 23.09.2017 06:47, Harald Welte wrote:
>
> http://cgit.osmocom.org/osmo-trx/commit/?id=e210f1a864b0752f5baeb14de8ddcfc7320007a4
>
> http://coccinelle.lip6.fr/sp.php - no sure if we want to replicate that in the
> osmocom wiki.


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




-------------- next part --------------
// spatch --c++ --dir src -I src --sp-file alloc.spatch --in-place --recursive-includes 
@@ expression A, B, C, D, E; @@
tbf_alloc_ul_tbf(A, B, C, D, E,
(
- 1
+ true
|
- 0
+ false
)
 )
@@ expression A, B, C, D, E; @@
tbf_alloc_dl_tbf(A, B, C, D, E,
(
- 1
+ true
|
- 0
+ false
)
 )
@@
identifier alloc_algorithm_a, bts, ms, tbf, cust, single, use_trx;
@@
alloc_algorithm_a(struct gprs_rlcmac_bts *bts, GprsMs *ms, struct gprs_rlcmac_tbf *tbf,
- uint32_t cust,
uint8_t single, int use_trx)
?{ ... }
@@ expression A, B, C, D, E, G; @@
alloc_algorithm_a(A, B, C,
-D,
E, G)
@@ expression A, B, C, D, E, G; @@
alloc_algorithm_b(A, B, C,
-D,
E, G)
@@ expression A, B, C, D, E, G; @@
alloc_algorithm_dynamic(A, B, C,
-D,
E, G)
@@ expression X, A, B, C, D, E, G; @@
X->alloc_algorithm(A, B, C,
-D,
E, G)