Kernel now supports for TID/I_TEI to be used in both IPv4 and IPv6 GTP
tunnels. This improves dualstack support for MS/UE so GTP traffic can
be identified with the same tunnel identifier.
Update gtp-tunnel to specify the family, since a tunnel is now
identified by the following tuple [ version, identifier, family ].
Change-Id: I584d3997ffb89cd430dfda9615a4ce0ce517ab2a
Implement IPv6 in libgtpnl and the gtp-tunnel testing tool. Allow to
combine:
- GTPA_MS_ADDRESS and GTPA_PEER_ADDR6
- GTPA_MS_ADDR6 and GTPA_PEER_ADDRESS
to specify IPv4-in-IPv6-GTP and IPv6-in-IPv4-GTP in the tunnel
declaration from control plane.
This patch is based on multiple patches from Pablo in OS#6123. I decided
to squash them to directly implement v4-in-v6 and vice versa, instead of
implementing another variant first and then changing it again.
Co-developed-by: Pablo Neira Ayuso <pablo@netfilter.org>
Related: OS#6096
Change-Id: If864c9170f74af52a95cbc4cdb1b866e0309306b
Make the file exactly the same as include/uapi/linux/gtp.h in
linux.git. GTPA_SGSN_ADDRESS is not used, but we decided to rather add
it and not have a diff.
Related: https://gerrit.osmocom.org/c/libgtpnl/+/34735/comment/909c69a6_2fe7781a/
Change-Id: Icf7b78e6655b6573c09c2eaa71d22ef6742b2594
Apply same fix as done by Pablo in linux.git:
> Subtract one to __GTPA_MAX, otherwise GTPA_MAX is off by 2
Change-Id: I42a358fc795d0e593e2c5509dcfa6ffdbad3cbfa
This aligns with a kernel patch that renames the netlink parameter
to emphasize that it refers to the remote peer which may be either
a GGSN or an SGSN.
The upstream kernel include file retains the legacy name as a define
but we don't need that in our internal library since we are no longer
using it anywhere.
This patch corresponds to a Linux kernel patch extending the kernel GTP
to also cover the SGSN role, not just the GGSN role. In order to keep
the API/behavior compatible, gtp_dev_create() will continue to create
GGSN-side tunnels, while a new gtp_dev_create_sgsn() is introduced to
create SGSN-side tunnels.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
GTPv1 tunnel use separate 32bit Tunnel Endpoint Identifier's for each
direction while GTPv0 uses only one 64bit Tunnel IDentifier.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
We can use this to specify 'gtp0' from openggsn, so we make sure that
it always uses the same tunnel device on creation. If it already exists,
it will return EEXIST. This is used to skip the problem of lacking
NLM_F_ECHO in the rtnetlink link interface that allows us to know the
name of the gtp device that has been dynamically allocated from the
kernel.
And, finally, I don't find any use case for having more than one tunnel
device when integrating this with openggsn.
This patch also adjusts tools/gtp-link-add.c which needs some care, since
it is not yet using any of the library functions. This tools are likely
to be useful for troubleshooting and debugging.
openggsn already sets up the UDP sockets that we need for the control
and user planes of GTP. Since we cannot bind two UDP sockets (one from
userspace and another from the kernel) to the same port, change the
current code to pass the socket descriptors that has been allocated
by openggsn (or whatever daemon which uses the GTP kernel
infrastructure).
Two new attributes are added to set up the tunnel device: IFLA_GTP_FD0
(for GTP0) and IFLA_GTP_FD1 (for GTP1u), which specify the UDP socket
created from userspace. Thus, the GTP kernel code only takes care of
enabling the kernel UDP encapsulation routine.
This patch adds a gtp_tunnel structure to avoid having to deal with
functions with lots of parameters. This should also help to extend
the interfaces and the gtp_tunnel object without breaking the binary
interface (which will be good by when ipv6 support will be added).
This patch adds the libgtpnl library. Harald mentioned that he wanted
that the specific code that is added is well encapsulated, so let's
start a small library to interact with the GTP kernel module via netlink
interface.
This was done a bit while in the rush, so the interfaces are not nice
at all and the tools need to be ported on top of this library.
This library will be used to integrate openggsn with the GTP kernel
module.
Pablo Neira Ayuso
Oliver Smith
Harald Welte