Hi all,
[intentionally breaking the thread here]
On Thu, Feb 23, 2017 at 05:46:57PM +0100, Harald Welte wrote:
> I'll try to cook up some instructions extending
> https://osmocom.org/projects/openggsn/wiki/OpenGGSN to cover also
> sgsnemu for a basic use case of establishing one single tunnel. That's
> of course like a manual "HOWTO" and not yet anything that can be tested
> automatically.
I've documented the instructions at
https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing
Please let me know any updates/corrections/questions if you try to
reproduce this. The above instructions were working for me yesterday.
Please find an ASCII export of this below (much less readable than the
wiki).
Regards,
Harald
h1. Basic Testing
This page documents some basic testing setup for the Kenrel GTP-U code. It follows the below rationale:
* focus on testing the kernel GTP-U module without too much external dependencies
* test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role)
* limit testing to SGSN/S-GW and GGSN/P-GW, without a real cellular network (which is possible e.g. using [[OsmoSGSN:]] and [[OsmoPCU:]])
h2. Building / Installing dependencies
In order to follow below test instructions, you will need
* A Linux kernel including the GTP-U driver (@drivers/net/gtp.c@) either compiled-in or as kernel module
* [[libgtpnl]] - the userspace library providing an API around the kernel GTP-U netlink interface
* [[OpenGGSN:]] - a minimal C-language implementation of a 3GPP GGSN, also contains a SGSN-side emulator called [[OpenGGSN:sgsnemu]]
** make sure you use Version 0.93 or later
** make sure you compile it with @--enable-gtp-linux@ enable during the @./configure@ step
You can find some instructions on how to build [[OpenGGSN:]] with support for [[libgtpnl]] and kernel GTP-U at this wiki page: [[OpenGGSN:Kernel_GTP]]
h2. Test setup description
We will run the GGSN natively on the host, and put the emulated SGSN inside a separate network namespace.
The two namespaces are interconnected by a virtual ethernet device using the transfer network 172.31.1.0/24
The GGSN is configured to provide a pool of IP addresses from the 192.168.71.0/24 range. Each PDP context will be allocated one dynamic address from that pool
h2. Test instructions
h3. create the network namespace for the SGSN
ip netns add sgsn
h3. add veth to be used between SGSN and GGSN
ip link add veth0 type veth peer name veth1
h3. remote (SGSN) side of veth device
<pre>
ip link set veth1 netns sgsn
ip netns exec sgsn ip addr add 172.31.1.2/24 dev veth1
ip netns exec sgsn ip link set veth1 up
</pre>
h3. local (GGSN) side of veth device
<pre>
ip addr add 172.31.1.1/24 dev veth0
ip link set veth0 up
</pre>
h3. execute the GGSN on the host
ggsn -g -c ./ggsn.conf.test
(use the file attached to this wiki page)
The @-g@ option is responsible for activating kernel-GTP support. If you cannot get the example described in this document to work, try the pure GTP-U userspace implementation by removing @-g@ from the above command line. If it works then, there's something related to Kernel GTP-U that breaks the setup.
h3. execute the emulated SGSN inside the sgsn namespace
ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2 --defaultroute --createif
h3. verify the existnace of the GTP tunnel
<pre>
ggsn:~# gtp-tunnel list
version 1 tei 1/1 ms_addr 192.168.71.2 sgsn_addr 172.31.1.2
</pre>
h3. further testing
in the @sgsn@ namespace, there's now a default-route that points into the GTP tunnel. You can use this to ping any network address that's reachable to the GGSN host. If that host is connected to the internet, you can e.g. run a ping command from within the namespace using
ip netns exec sgsn ping -c 10 8.8.8.8
which will send some IP packets to 8.8.8.8 via the tun0 device (created by [[OpenGGSN:sgsnemu]]). It will be encapsulated by the userspace GTP-U implementation of sgsnemu, sent via the veth device to the host, where it ends up inthe GTP-U kernel module, decapsulating the package and passing in on to the gtp0 device there. Anything beyond that point depends on your local routing configuration.
== Building OpenGGSN ==
h1. OpenGGSN and Linux Kernel accelerated GTP-U
OpenGGSN has support to use the Linux kernel GTP-U code to accelerate the data/user plane while still implementing the control plane (GTP-C) in userspace in OpenGGSN.
For more information about the Linux kernel GTP-U code, please see [[linux-kernel-gtp-u:]]
h2. Building OpenGGSN with kernel which has GTP-U support
At the time of writing (2017-01-09) of this wiki, below listed distributions have support of GTP kernels :
* Debian 4.9.1-1~exp1 - Debian's latest experimental build
* Ubuntu 16.10 kernel 4.8
* OpenSUSE Tumbleweed (stable) 4.8 (.12)
* Fedora 25 kernel 4.8
Following two Debian kernels do not activate GTP kernel module during build: 4.8.0 and 4.9.0.
*It is expected that complete openbsc project and related dependencies are pre-installed.*
Check if package @libc-ares-dev@ is installed and if not please add it.
Ubuntu 16.10, kernel 4.8.0-30-generic is used.
* Installing dependencies and build library @libgtpnl@
You can install those packages with:
<pre>
sudo apt install libtalloc-dev libpcsclite libmnl-dev
</pre>
Please follow instructions provided at [[cellular-infrastructure:Build from source]] in order to install following library and projects :
Information about dependencies between Osmocom projects is given at the above link:
* libgtpnl
<pre>
sudo make install
sudo ldconfig
</pre>
* libosmocore
* openggsn
<pre>
./configure --enable-gtp-linux
make
sudo make install
sudo ldconfig
</pre>
Following message is shown at end of the command: @ ./configure --enable-gtp-linux@
<pre>
openggsn Configuration:
GTP Linux kernel support: yes
</pre>
This means that appropriate header files are available.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Pablo,
This is v4 of the GTP improvements. Compared to v3 it contains mostly
smallish naming and spelling fixes. It also drops the documentation
patch, Harald did a better job with the documentation and the some things
I described do not yet match the implementation. I'll readd the relevant
parts with a follow up series.
This series lays the groundwork for removing the socket references from
the GTP netdevice by removing duplicate code and simplifying the logic on
some code paths.
It slighly changes the GTP genl API by making the socket parameters optional
(though one of them is still required).
The removal of the socket references will break the 1:1 releation between
GTP netdevice and GTP socket that prevents us to support multiple VRFs with
overlaping IP addresse spaces attached to the same GTP-U entity (needed for
multi APN support, comming a follow up series).
Pablo found a socket hold problem in v2. In order to solve that I had to
switch the socket references from the struct socket to the internal
struct sock. This should have no functionl impact, but we can now hang
on to the reference without blocking user space from closing the GTP socket.
v3->v4:
* drop the documentation patch
* spelling fixes
* pass nlattr instead of genl_info into gtp_find_dev,
makes the code slightly more compact and readable
v2->v3:
* add documentation to explain the goal of all these changes
* incorporate review comments
* switch from struct socket to struct sock
Regards
Andreas
--
Andreas Schultz (7):
gtp: switch from struct socket to struct sock for the GTP sockets
gtp: make GTP sockets in gtp_newlink optional
gtp: merge gtp_get_net and gtp_genl_find_dev
gtp: consolidate gtp socket rx path
gtp: unify genl_find_pdp and prepare for per socket lookup
gtp: consolidate pdp context destruction into helper
gtp: add socket to pdp context
drivers/net/gtp.c | 543 +++++++++++++++++++++++++++---------------------------
1 file changed, 269 insertions(+), 274 deletions(-)
--
2.10.2
Hi Pablo,
This is v3 of the GTP improvements.
This series lays the groundwork for removing the socket references from
the GTP netdevice by removing duplicate code and simplifying the logic on
some code paths.
It slighly changes the GTP genl API by making the socket parameters optional
(though one of them is still required).
The removal of the socket references will break the 1:1 releation between
GTP netdevice and GTP socket that prevents us to support multiple VRFs with
overlaping IP addresse spaces attached to the same GTP-U entity (needed for
multi APN support).
Pablo found a socket hold problem in v2. In order to solve that I had to
switch the socket references from the struct socket to the internal
struct sock. This should have no functionl impact, but we can now hang
on to the reference without blocking user space from closing the GTP socket.
There was also some length off-list conversation about why the netdevice to
socket relation needs to be changed at all. Harald did already agree to this
but Pablo had some questions. I've tried to address that with a bit of
dokumentation for the GTP module. Hopefully this will explain the need for
the change sufficiently.
This series does have conflicts with the SGSN side tunnel work done by
Jonas Bonn. The unification of the tunnel Rx code touches the same places
he changed.
v2->v3:
* add documentation to explain the goal of all these changes
* incorporate review comments
* switch from struct socket to struct sock
Regards
Andreas
--
Andreas Schultz (8):
gtp: add documentation
gtp: switch from struct socket to struct sock for the GTP sockets
gtp: make GTP sockets in gtp_newlink optional
gtp: merge gtp_get_net and gtp_genl_find_dev
gtp: consolidate gtp socket rx path
gtp: unify genl_find_pdp and prepare for per socket lookup
gtp: consolidate pdp context destruction into helper
gtp: add socket to pdp context
Documentation/networking/gtp.txt | 112 ++++++++
drivers/net/gtp.c | 548 +++++++++++++++++++--------------------
2 files changed, 386 insertions(+), 274 deletions(-)
create mode 100644 Documentation/networking/gtp.txt
--
2.10.2
Hello,
I want to use the local sims having different MNC/MCC for implementing GPRS
using osmocoms with OpenBTS same as I have used them for GSM calls and sms
using only openBTS. But your site
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently
not possible". As it is long when posted on this site so I want to ask is
it possible *now* to use the local sims? Hope you have understood my
question. Waiting for your reply. Thanks.
Regards,
Saba Arshad
Hi ,
Posting question related to capability to implement user plane (GTP tunnel) for S1-U and Iu-PS interface between S-GW & eNB and SGSN & RNC respectively via osmocom kernel GTP-U module.
At present it seems if TE-ID is not valid packet is dropped in kernel GTP-U module. So in order to use this for S1-U/Iu-PS interface it is required to add support for following use-case:
* Down link packet arrival in S-GW /SGSN for UE which is in idle mode - Buffer the packet and trigger paging to move the UE to connected.
a. When UE moves to idle mode - S1-U or IuPS bearer is released. In this case IP address and TE-ID of eNB/RNC becomes invalid.
b. DL Packet is received for the idle mode UE in S-GW/SGSN - In this case , kernel GTP-U module should deliver packet to user-space application (SGW/osmoSGSN) so that these packets can be buffered in user space and paging can be initiated.
Question - Is there any plan to support above in near-future in osmocom kernel GTP-U module or larger question would be to plan to enable usage of kernel GTP-U module in SGSN and SGW towards RAN ?
Thanks,
Anoop
Dear GTP-interested folks,
I would love to somehow get towards some degree of unit testing (or even
"continuous integration") for teh kernel GTP code.
We currently have the original code in the kernel, we had some recent
small fixes and now are getting more patches into place. With
relatively few active users out there (and probably none of them in
production yet), it's particularly easy to introduce regressions while
working on the code. Also, having tested new code even against a
test set with limited covrage could help to get more confidence in new
patches and thus get them merged sooner.
Using tools like sgsnemu of OpenGGSN and the command line tools included
in libgtpnl, it should be possibel to cook up some scripts for testing.
Even the most basic set of tests would be an improvement over what we
have now. One could also think about pcap replay to test with
hand-crafted or real-world packets from other GTP implementations.
As much as I'd like to put something like this into place myself, I
don't think I will be able to work much on this in the near future. The
GTP module at this point is a pure hobby and contrary to some years ago
while I started it, I don't have any contract work in the GTP area at
this point, so other projects currently unfortunately get more
attention.
So in case somebody among the GTP-interested parties (Travelping, OAI,
...) would want to do something in terms of testing, I'd be more than
happy if somebody would step ahead. Otherwise it's all just vapourware
going to end up on my ever-growing TODO list :/
Also, if netdev folks have some ideas/pointers about possible
frameworks/tools for this kind of testing [it must exist for at least
some other kernel networking code?]: Please let me know. I'd be
interested to have a look if there's something that can be used as a
basis (starting network namespaces, sending/transmitting packets, test
case startup/teardown, ...)
My "old school" approach would have been to start one or multiple
user-mode-linux kernels (those that are to be tested), and then have
scripts that set up a gtp socket and gtp tunnels via the libgtp command
line tools, and throw packets at that. But I'm sure there must be
quite powerful frameworks for that kind of testing in the 21st century?
How do other tunneling implementations handle this?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Andreas, Pablo, Jonas,
I think that the SGSN/GGSN role flag (or whatever it may end up being
called) logically belongs in the gtp-device at this point, and will in
the future belong to the UDP/GTP-socket (with Andreas' proposed
changes). Having it per-pdp-context indeed seems odd and just provide
a way to create broken configurations (and increase the memory use per
pdp context, of which you have many more than netdevs or gtp-sockets).
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)