osmo-ggsn/ggsn/gtp-kernel.c

202 lines
4.4 KiB
C
Raw Normal View History

ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
#ifdef __linux__
#define _GNU_SOURCE 1 /* strdup() prototype, broken arpa/inet.h */
#endif
#include "../config.h"
#ifdef HAVE_STDINT_H
#include <stdint.h>
#endif
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <inttypes.h>
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
#include <sys/types.h>
#include <arpa/inet.h>
#include <net/if.h>
#include <libgtpnl/gtp.h>
#include <libgtpnl/gtpnl.h>
#include <libmnl/libmnl.h>
#include <errno.h>
#include <time.h>
#include "../lib/tun.h"
#include "../lib/syserr.h"
#include "../gtp/pdp.h"
#include "../gtp/gtp.h"
#include <libgtpnl/gtp.h>
#include <libgtpnl/gtpnl.h>
#include <libmnl/libmnl.h>
#include "gtp-kernel.h"
static void pdp_debug(struct pdp_t *pdp)
{
struct in46_addr ia46;
struct in_addr ia;
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
in46a_from_eua(&pdp->eua, &ia46);
gsna2in_addr(&ia, &pdp->gsnrc);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
LOGPDPX(DGGSN, LOGL_DEBUG, pdp, "v%u TEID %"PRIu64"x EUA=%s SGSN=%s\n", pdp->version,
pdp->version == 0 ? pdp_gettid(pdp->imsi, pdp->nsapi) : pdp->teid_gn,
in46a_ntoa(&ia46), inet_ntoa(ia));
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
}
static struct {
int genl_id;
struct mnl_socket *nl;
} gtp_nl;
static int gtp_kernel_init_once(void)
{
/* only initialize once */
if (gtp_nl.nl)
return 0;
gtp_nl.nl = genl_socket_open();
if (gtp_nl.nl == NULL) {
SYS_ERR(DGGSN, LOGL_ERROR, 0, "cannot create genetlink socket\n");
return -1;
}
gtp_nl.genl_id = genl_lookup_family(gtp_nl.nl, "gtp");
if (gtp_nl.genl_id < 0) {
SYS_ERR(DGGSN, LOGL_ERROR, 0,
"cannot lookup GTP genetlink ID\n");
genl_socket_close(gtp_nl.nl);
gtp_nl.nl = NULL;
return -1;
}
SYS_ERR(DGGSN, LOGL_DEBUG, 0, "Initialized GTP kernel mode (genl ID is %d)\n", gtp_nl.genl_id);
return 0;
}
int gtp_kernel_init(struct gsn_t *gsn, const char *devname, struct in46_prefix *prefix, const char *ipup)
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
{
struct in_addr net;
const char *net_arg;
if (!gtp_nl.nl)
gtp_kernel_init_once();
if (prefix->addr.len != 4) {
SYS_ERR(DGGSN, LOGL_ERROR, 0,
"we only support IPv4 in this path :/");
return -1;
}
net = prefix->addr.v4;
if (gtp_dev_create(-1, devname, gsn->fd0, gsn->fd1u) < 0) {
SYS_ERR(DGGSN, LOGL_ERROR, 0,
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
"cannot create GTP tunnel device: %s\n",
strerror(errno));
return -1;
}
net_arg = in46p_ntoa(prefix);
DEBUGP(DGGSN, "Setting route to reach %s via %s\n", net_arg, devname);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
if (gtp_dev_config(devname, &net, prefix->prefixlen) < 0) {
SYS_ERR(DGGSN, LOGL_ERROR, 0,
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
"Cannot add route to reach network %s\n",
net_arg);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
}
/* launch script if it is set to bring up the route to reach
* the MS, eg. ip ro add 10.0.0.0/8 dev gtp0. Better add this
* using native rtnetlink interface given that we know the
* MS network mask, later.
*/
if (ipup) {
char cmd[1024];
int err;
/* eg. /home/ggsn/ipup gtp0 10.0.0.0/8 */
snprintf(cmd, sizeof(cmd), "%s %s %s", ipup, devname, net_arg);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
cmd[sizeof(cmd)-1] = '\0';
err = system(cmd);
if (err < 0) {
SYS_ERR(DGGSN, LOGL_ERROR, 0,
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
"Failed to launch script `%s'", ipup);
return -1;
}
}
SYS_ERR(DGGSN, LOGL_NOTICE, 0, "GTP kernel configured\n");
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
return 0;
}
void gtp_kernel_stop(const char *devname)
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
{
gtp_dev_destroy(devname);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
}
int gtp_kernel_tunnel_add(struct pdp_t *pdp, const char *devname)
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
{
struct in_addr ms, sgsn;
struct gtp_tunnel *t;
int ret;
pdp_debug(pdp);
t = gtp_tunnel_alloc();
if (t == NULL)
return -1;
memcpy(&ms, &pdp->eua.v[2], sizeof(struct in_addr));
memcpy(&sgsn, &pdp->gsnrc.v[0], sizeof(struct in_addr));
gtp_tunnel_set_ifidx(t, if_nametoindex(devname));
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
gtp_tunnel_set_version(t, pdp->version);
gtp_tunnel_set_ms_ip4(t, &ms);
gtp_tunnel_set_sgsn_ip4(t, &sgsn);
if (pdp->version == 0) {
gtp_tunnel_set_tid(t, pdp_gettid(pdp->imsi, pdp->nsapi));
gtp_tunnel_set_flowid(t, pdp->flru);
} else {
gtp_tunnel_set_i_tei(t, pdp->teid_own);
/* use the TEI advertised by SGSN when sending packets
* towards the SGSN */
gtp_tunnel_set_o_tei(t, pdp->teid_gn);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
}
ret = gtp_add_tunnel(gtp_nl.genl_id, gtp_nl.nl, t);
gtp_tunnel_free(t);
return ret;
}
int gtp_kernel_tunnel_del(struct pdp_t *pdp, const char *devname)
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
{
struct gtp_tunnel *t;
int ret;
pdp_debug(pdp);
t = gtp_tunnel_alloc();
if (t == NULL)
return -1;
gtp_tunnel_set_ifidx(t, if_nametoindex(devname));
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
gtp_tunnel_set_version(t, pdp->version);
if (pdp->version == 0) {
gtp_tunnel_set_tid(t, pdp_gettid(pdp->imsi, pdp->nsapi));
gtp_tunnel_set_flowid(t, pdp->flru);
} else {
gtp_tunnel_set_i_tei(t, pdp->teid_own);
ggsn: add support for GTP kernel data encapsulation This patch adds the -g, --gtpnl=device option that allows you to enable the GTP kernel tunneling mode in openggsn. You have to specify the real downlink device that will be used to tunnel traffic, eg. -g=eth0 This means that the gtp0 device will be created and it will use eth0 as the real device to encapsulate packet coming from the Internet that are addressed to the MS (so the tunnel devuce encapsulates these IP packets in GTP packets when traveling to the SGSN). Alternatively, you can also add this to the ggsn.conf configuration file: gtpnl eth0 The device has to be the real device that can route packets to the SGSN, if you select the wrong device, the kernel routing code may not find a way to reach the SSGN, you've been warned. Therefore, if this option is set, the operational becomes the following: 1) A gtp0 device is created via rtnetlink and configure the socket encapsulation infrastructure in the kernel. 2) Whenever a PDP context is created, this adds the necessary tunnel configuration via genetlink GTP interface. 3) Whenever a PDP context is destroyed, this deletes the tunnel via genetlink GTP interface. 4) Destroy the gtp0 device if ggsn is stopped, including all of the existing tunnels. You require the osmo-ggsn.git tree, which contains the kernel module gtp.ko and the libgtpnl library that you have to compile and install. Make sure you have loaded the gtp.ko kernel module before launching the ggsn daemon using the kernel driver mode, otherwise you will get a nice "operation not supported" error message ;-). This patch also adds supports for "ipup" configuration option to invoke an external script after the gtp0 device has been brought up. Typical command to add the route to reach the MS behind the GGSN is required, eg. ip route add 10.0.0.0/8 dev gtp0. The (horrible) ggsn parser has been manually extended to support the new configuration option. That code doesn't look nice, but it just mimics what we already have there for consistency, please don't blame me for that. If you want to run in debugging mode, I suggest you to use: sudo ggsn -c ggsn.conf -f -d Note that you do have to run openggsn as root to bring up the gtp0 device. You have to see this message that announce that the GTP kernel mode is enabled. openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25) This patch also automagically sets up route to reach MS from Internet just like tun mode does. This is fundamental to get this working, better don't leave to the admin, he may forget to add this route. In this patch, I tried to encapsulate this new feature as much as possible as Harald initially suggested. To compile this feature, you have to pass --enable-gtp-kernel, ie. ./configire --enable-gtp-kernel Otherwise, the code to interact with the gtp kernel part is not compiled. Signed-off-by: Andreas Schultz <aschultz@tpip.net>
2015-11-17 11:22:42 +00:00
}
ret = gtp_del_tunnel(gtp_nl.genl_id, gtp_nl.nl, t);
gtp_tunnel_free(t);
return ret;
}