From alandrecm at tipbrasil.com.br  Tue Apr  4 16:32:32 2017
From: alandrecm at tipbrasil.com.br (Alandre de Carvalho)
Date: Tue, 4 Apr 2017 13:32:32 -0300
Subject: GTP echo response
Message-ID: <013b01d2ad61$0f2ff5c0$2d8fe140$@tipbrasil.com.br>

Hi everyone,

 

We're using kernel GTP developed by Osmocom on openair-cn. Turns out that we
are not able to connect an UE for longer than 20 seconds using an ZTE eNB
apparently because the GTP-U is not answering to the echo requests. As far I
know this response is supposed to be implemented but it is not answering. Do
you guys have any tips on this issue?

 

Thanks in advance,

 

Alandre

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170404/232f86fc/attachment.htm>

From aschultz at tpip.net  Wed Apr  5 10:26:36 2017
From: aschultz at tpip.net (Andreas Schultz)
Date: Wed, 5 Apr 2017 12:26:36 +0200 (CEST)
Subject: GTP echo response
In-Reply-To: <013b01d2ad61$0f2ff5c0$2d8fe140$@tipbrasil.com.br>
References: <013b01d2ad61$0f2ff5c0$2d8fe140$@tipbrasil.com.br>
Message-ID: <80603573.746464.1491387996651.JavaMail.zimbra@tpip.net>

Hi Alandre,

----- On Apr 4, 2017, at 6:32 PM, Alandre de Carvalho alandrecm at tipbrasil.com.br wrote:

> Hi everyone,

> We?re using kernel GTP developed by Osmocom on openair-cn. Turns out that we are
> not able to connect an UE for longer than 20 seconds using an ZTE eNB
> apparently because the GTP-U is not answering to the echo requests. As far I
> know this response is supposed to be implemented but it is not answering. Do
> you guys have any tips on this issue?

I don't know how OpenAir-CN uses the kernel module, but Echo handling
is not part of the kernel implementation. 

The kernel will pass all GTP-U packets that do not match a PDP context
(this applies to Echo Request) up to the user space management process
which then has to generate the proper response. 

Your problem feels a bit like the OAI-CN userspace is not handling the
echo requests. Maybe it's not implemented? 

Regards 
Andreas 

> Thanks in advance,

> Alandre


From alandrecm at tipbrasil.com.br  Wed Apr  5 10:51:29 2017
From: alandrecm at tipbrasil.com.br (Alandre De Carvalho)
Date: Wed, 5 Apr 2017 07:51:29 -0300
Subject: GTP echo response
In-Reply-To: <80603573.746464.1491387996651.JavaMail.zimbra@tpip.net>
References: <013b01d2ad61$0f2ff5c0$2d8fe140$@tipbrasil.com.br>
 <80603573.746464.1491387996651.JavaMail.zimbra@tpip.net>
Message-ID: <4563383D-0ADA-46C3-B133-DFA3F741ADB5@tipbrasil.com.br>

Hi Andreas,

Thanks for your responde. I'm going to check on OAI.

Thank you 

Alandre

Sent from my iPhone

> On 5 Apr 2017, at 07:26, Andreas Schultz <aschultz at tpip.net> wrote:
> 
> Hi Alandre,
> 
> ----- On Apr 4, 2017, at 6:32 PM, Alandre de Carvalho alandrecm at tipbrasil.com.br wrote:
> 
>> Hi everyone,
> 
>> We?re using kernel GTP developed by Osmocom on openair-cn. Turns out that we are
>> not able to connect an UE for longer than 20 seconds using an ZTE eNB
>> apparently because the GTP-U is not answering to the echo requests. As far I
>> know this response is supposed to be implemented but it is not answering. Do
>> you guys have any tips on this issue?
> 
> I don't know how OpenAir-CN uses the kernel module, but Echo handling
> is not part of the kernel implementation. 
> 
> The kernel will pass all GTP-U packets that do not match a PDP context
> (this applies to Echo Request) up to the user space management process
> which then has to generate the proper response. 
> 
> Your problem feels a bit like the OAI-CN userspace is not handling the
> echo requests. Maybe it's not implemented? 
> 
> Regards 
> Andreas 
> 
>> Thanks in advance,
> 
>> Alandre



From ouyangj at fb.com  Thu Apr 20 21:08:31 2017
From: ouyangj at fb.com (Jiannan Ouyang)
Date: Thu, 20 Apr 2017 21:08:31 +0000
Subject: kernel GTP-U support dev roadmap
Message-ID: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>

Hi Harald and Andreas,

I?m writing to inquiry about the development roadmap of the kernel gtp module. For example, is there any plan to support the following features soon
- lightweight tunnel
- ipv6

The openair-cn project I?m working on is a user of the kernel gtp module. I?m happy to help improve the kernel gtp support, so it?s good to first ask about the roadmap.

Regards,
-Jiannan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170420/401185c8/attachment.htm>

From hwelte at sysmocom.de  Thu Apr 20 22:21:01 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Fri, 21 Apr 2017 00:21:01 +0200
Subject: kernel GTP-U support dev roadmap
In-Reply-To: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>
References: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>
Message-ID: <20170420222101.etlw6qk6tjwgahbn@nataraja>

Hi Jiannan,

On Thu, Apr 20, 2017 at 09:08:31PM +0000, Jiannan Ouyang wrote:
> I?m writing to inquiry about the development roadmap of the kernel gtp
> module. For example, is there any plan to support the following
> features soon

There is no "roadmap" from my point of view, as I (and the sysmocom
team) currently have no customer requirements/requests/projects on this.
As sysmocom is not a group of volunteers doing things in their spare
time but a team of paid engineers, we can primarily work only on those
topics where there are customer requirements.

For Pablo (another co-author of the module) it is the same.

I'm very happy to do project based work around the kernel GTP module,
in whatever direction, just as long as it is about generally useful
features while within relevant specifications and architecturally fits
the code and the Linux kernel stack.

For Andreas and his employer Travelping the situation is quite
different.  As far as I understand they do have customer
projects/requirements  that drive the development.  But I can of course
not speak for him, and he can comment on this himself.

> The openair-cn project I?m working on is a user of the kernel gtp
> module. I?m happy to help improve the kernel gtp support, so it?s good
> to first ask about the roadmap.

If you can work on it, by all means do so.  I think particularly the
IPv6 support (both on the user payload (inner IP) as well as the outer
transport IP is much appreciated by everyone.

It may make sense to coordinate with Andreas, to make sure there's not
too many merge conflicts between his work and yours.

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


From ouyangj at fb.com  Fri Apr 21 19:18:32 2017
From: ouyangj at fb.com (Jiannan Ouyang)
Date: Fri, 21 Apr 2017 19:18:32 +0000
Subject: kernel GTP-U support dev roadmap
In-Reply-To: <20170420222101.etlw6qk6tjwgahbn@nataraja>
References: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>
 <20170420222101.etlw6qk6tjwgahbn@nataraja>
Message-ID: <1192AD19-70CA-4BCD-9CB2-8064EB981070@fb.com>

Hi Harald,

On 4/20/17, 3:21 PM, "Harald Welte" <hwelte at sysmocom.de> wrote:

>   If you can work on it, by all means do so.  I think particularly the
>    IPv6 support (both on the user payload (inner IP) as well as the outer
>    transport IP is much appreciated by everyone.

Currently, I?m investigating lightweight tunnel (lwt) support for gtp, 
a wishlist feature listed on your netdev talk.

Please correct me if I?m wrong:
gtp.ko currently uses the genl interface to talk to libgtpnl in userspace for 
tunnel management. With lwt support, it is possible to manage gtp tunnels 
with iproute2 commands. In this case, libgtpnl may be deprecated and 
replaced by iproute2 in the future. Is that correct?

>    It may make sense to coordinate with Andreas, to make sure there's not
>    too many merge conflicts between his work and yours.

Andreas, would you please share your plan on the gtp kernel module?

Regards,
-Jiannan


From aschultz at tpip.net  Sat Apr 22 14:36:57 2017
From: aschultz at tpip.net (Andreas Schultz)
Date: Sat, 22 Apr 2017 16:36:57 +0200 (CEST)
Subject: kernel GTP-U support dev roadmap
In-Reply-To: <1192AD19-70CA-4BCD-9CB2-8064EB981070@fb.com>
References: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>
 <20170420222101.etlw6qk6tjwgahbn@nataraja>
 <1192AD19-70CA-4BCD-9CB2-8064EB981070@fb.com>
Message-ID: <608272194.996412.1492871817584.JavaMail.zimbra@tpip.net>

Hi Jiannan,

----- On Apr 21, 2017, at 9:18 PM, Jiannan Ouyang ouyangj at fb.com wrote:

> Hi Harald,
> 
> On 4/20/17, 3:21 PM, "Harald Welte" <hwelte at sysmocom.de> wrote:
> 
>>   If you can work on it, by all means do so.  I think particularly the
>>    IPv6 support (both on the user payload (inner IP) as well as the outer
>>    transport IP is much appreciated by everyone.
> 
> Currently, I?m investigating lightweight tunnel (lwt) support for gtp,
> a wishlist feature listed on your netdev talk.
> 
> Please correct me if I?m wrong:
> gtp.ko currently uses the genl interface to talk to libgtpnl in userspace for
> tunnel management. With lwt support, it is possible to manage gtp tunnels
> with iproute2 commands. In this case, libgtpnl may be deprecated and
> replaced by iproute2 in the future. Is that correct?

No. lw-tunnel use netlink attributes to store the tunnel destination. The
netlink attributes can then be attached to a routing entry. That way it
becomes possible to have tunneling information in the routing table or
pass them into the kernel module from another source, e.g. from a OpenFlow
rules in OpenVSwitch.
This would make it possible to use OF rules to put traffic into GTP tunnels.

The existing genl interface could be added to iproute2 with or without
libgtpnl and is completely independent from the lwt support.

>>    It may make sense to coordinate with Andreas, to make sure there's not
>>    too many merge conflicts between his work and yours.
> 
> Andreas, would you please share your plan on the gtp kernel module?

I don't have road map. As Harald already mentioned, we are mostly driven
by customer demand. The current functionality in the kernel module is
sufficient for their current needs.

There are a few things that I have added in my spare time like the
multi APN support or GTP over IPv6. These things can be found at:
https://github.com/RoadRunnr/net-next/commits/master/drivers/net/gtp.c

The last time I tried to push those change upstream they got rejected
by Pablo. One of the reasons is that I had to change the API ever so
slightly. Still, this violates the rule that kernel API can not be
changed, never, ever.

The other thing is that is has become clear that Pablo's idea of how
the GTP implementation should work in terms of APIs is completely
different from my ideas. Pablo's (and other kernel developers) seem
to prefer a implementation where static tunnels can be configured.
That mean the kernel own's the GTP tunnels and the interfaces and
operates completely independent from the user space control interface.
The user space entity could then be restarted without loosing the
tunnels.

I believe that the user space entity should own the sockets and
tunnels and that a termination of the user space control instance
should automatically remove all existing GTP tunnels (having GTP
forwarding without the control context is IMHO not a valid state
for any of the 3GPP GTP gateways).

We (Travelping) have not yet reached a final decision on how to deal
with the above problems. So, for the moment we are use what is there 
and concentrate on adding other major missing pieces of functionality 
that our customer have requested to our OpenSource GGSN/PGW implementation.
The  current focus there is one the Gx and Gy interfaces with the
monitoring, charging, traffic redirection and QoS functions.

Other future projects in the 3GPP space include a SGW implementation
and eventually a MME (although this might be restricted to the
functions required for NB-IoT).

All of this is of course is driven by customer demand and might and can be
changed when the demand changes.

Regards
Andreas

> 
> Regards,
> -Jiannan


From ouyangj at fb.com  Mon Apr 24 19:15:14 2017
From: ouyangj at fb.com (Jiannan Ouyang)
Date: Mon, 24 Apr 2017 19:15:14 +0000
Subject: kernel GTP-U support dev roadmap
In-Reply-To: <608272194.996412.1492871817584.JavaMail.zimbra@tpip.net>
References: <0D7560CB-5B4E-4D3D-8A39-6B96D34E4F63@fb.com>
 <20170420222101.etlw6qk6tjwgahbn@nataraja>
 <1192AD19-70CA-4BCD-9CB2-8064EB981070@fb.com>
 <608272194.996412.1492871817584.JavaMail.zimbra@tpip.net>
Message-ID: <DDA54D34-81EA-4A08-B038-6A3AB37918FE@fb.com>

Hi Andreas, 

Thanks for your detailed information. They are very helpful!

On 4/22/17, 7:36 AM, "Andreas Schultz" <aschultz at tpip.net> wrote:

>    No. lw-tunnel use netlink attributes to store the tunnel destination. The
>    netlink attributes can then be attached to a routing entry. That way it
>    becomes possible to have tunneling information in the routing table or
>    pass them into the kernel module from another source, e.g. from a OpenFlow
>    rules in OpenVSwitch.
>    This would make it possible to use OF rules to put traffic into GTP tunnels.
>    
>    The existing genl interface could be added to iproute2 with or without
>    libgtpnl and is completely independent from the lwt support.
    
My understanding is that the netlink attributes used by lw-tunnel are natually 
supported by iproute2 or Openvswitch, e.g.

ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0

The genl interface is customized for libgtpnl. Having one of two interfaces should 
be enough to manage GTP tunnels from userspace. Is there a reason that we prefer
one over the other? Specifically, why do we use genl instead of netlink, and why use 
a customized userspace library instead of iproute2?

>    The last time I tried to push those change upstream they got rejected
>    by Pablo. One of the reasons is that I had to change the API ever so
>    slightly. Still, this violates the rule that kernel API can not be
>    changed, never, ever.
  
Is the ?kernel API? referring to the genl interface?
  
>    The other thing is that is has become clear that Pablo's idea of how
>    the GTP implementation should work in terms of APIs is completely
>    different from my ideas. Pablo's (and other kernel developers) seem
>    to prefer a implementation where static tunnels can be configured.
>    That mean the kernel own's the GTP tunnels and the interfaces and
>    operates completely independent from the user space control interface.
>    The user space entity could then be restarted without loosing the
>    tunnels.
>    
>    I believe that the user space entity should own the sockets and
>    tunnels and that a termination of the user space control instance
>    should automatically remove all existing GTP tunnels (having GTP
>    forwarding without the control context is IMHO not a valid state
>    for any of the 3GPP GTP gateways).

In my opinion, both design looks reasonable as long as one entity owns all the state, 
either it?s the kernel or a user space control process. However, I believe that GTP 
is just one of the many tunneling protocols supported by Linux. Thus, it should have 
consistent behaviors comparing with other tunnels. Seems for most tunnels, the kernel 
maintains the state and expose management interface to userspace programs; control
processes are mostly stateless.

Nevertheless, ?a termination of the user space control instance should automatically
remove all existing GTP tunnels? is a valid point. I think this could be implemented in the
exiting procedure or destructor of the control process, while carefully taking care of the 
process crashing case.

>    Regards
>    Andreas

Regards,
Jiannan    


From laforge at gnumonks.org  Tue Apr 25 06:58:15 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 25 Apr 2017 08:58:15 +0200
Subject: Video Recordings of OsmoCon 2017
Message-ID: <20170425065815.66b3j4ctwchm23k3@nataraja>

Hi all,

the Osmocom Conference 2017 last week was an overwhelming success.  We
received lots of positive feedback from all sides.  Thanks to all the
speakers, to the attendees as well as to the anonymous sponsor of the
travel grant funds.

It is my great pleasure that due to the great support by C3VOC (The CCC
Video Operation Center), we have full recordings of all talks given at
OsmoCon 2017.

You can find the videos on the C3VOC site at
https://media.ccc.de/search/?q=osmocon

They are also linked individually from the OsmoCon 2017 homepage at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017

I hope the video recordings will be of help for everyone who could not
make it to the event in person.

We will also be collecting the slides and put them up on the wiki during
the next few days.

Please don't hesitate to raise any feedback and/or questions.

Technical feedback/questions regarding Osmocom software / projects
should be addressed to the appropriate mailing lists, such as
openbsc at lists.osmocom.org.

Feedback to the organizers should be sent to osmocon2017 at sysmocom.de.

Looking forward to the next OsmoCon, which we'll expect to be spanning
ore than just a single day.

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)