Project

General

Profile

Actions

Feature #6096

open

add support for kernel-GTP IPv6

Added by laforge 8 months ago. Updated 12 days ago.

Status:
In Progress
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
07/12/2023
Due date:
% Done:

50%

Spec Reference:

Description

pablo has implemented [inner] IPv6 support in the kernel GTP driver and libgtpnl, see #1952

In order to end-to-end test it in our TTCN3 test suite (which already tests ipv6 when used with userspace GTP), we would need to add supprot for it to osmo-ggsn

I think pespin is currently too busy to look at this, hence assigned to osmith, but that's not mandatory. Feel free to pass around as needed.


Related issues

Related to Linux Kernel GTP-U - Bug #1952: IPv6 support for inner (user) IP layer missingIn Progresspablo02/18/2017

Actions
Related to OsmoGGSN (former OpenGGSN) - Bug #6106: OsmoGGSN attempts to use the same GTP-U socket for all APNs with gtpu-mode kernel-gtpNew07/21/2023

Actions
Related to Linux Kernel GTP-U - Bug #1953: IPv6 support for outer (transport) IP layer missingResolved02/18/2017

Actions
Blocked by Linux Kernel GTP-U - Bug #6123: IPv4/IPv6 address family has to be the same for inner layer and outer layerResolvedpablo07/31/2023

Actions
Actions #1

Updated by laforge 8 months ago

  • Related to Bug #1952: IPv6 support for inner (user) IP layer missing added
Actions #3

Updated by osmith 8 months ago

  • Status changed from New to In Progress
Actions #4

Updated by osmith 8 months ago

  • Subject changed from add supprot for kernel-GTP IPv6 to add support for kernel-GTP IPv6
Actions #5

Updated by osmith 7 months ago

  • % Done changed from 0 to 30

With https://gerrit.osmocom.org/c/osmo-ggsn/+/33797 and https://gerrit.osmocom.org/c/docker-playground/+/33802 the kernel module can be used for ipv6 and some of the ipv6 and ipv4v6 tests start passing.

However it is not possible currently to configure multiple APNs with the kernel module (in the osmo-ggsn.cfg that does not use the kernel module, we have extra APNs for ipv4, ipv4v6 and ipv6). I'm not sure if this is in scope of this issue or needed at all.

Actions #6

Updated by laforge 7 months ago

On Tue, Jul 18, 2023 at 03:10:20PM +0000, osmith wrote:

However it is not possible currently to configure multiple APNs with the kernel module (in the osmo-ggsn.cfg that does not use the kernel module, we have extra APNs for ipv4, ipv4v6 and ipv6). I'm not sure if this is in scope of this issue or needed at all.

I'm a bit surprised by that constraint. Why would the kernel module care about APNs?

After all, the APN is a completely logical construct, nothing more than an
identifier (spoken only on the GTP-C control plane) to identify the network
device (and hence address pool and where to route packets).

Actions #7

Updated by laforge 7 months ago

On Tue, Jul 18, 2023 at 03:10:20PM +0000, osmith wrote:

However it is not possible currently to configure multiple APNs with the kernel module

I've now re-checked and couldn't find any mention of that constraint in the user manual, nor would
I see why code in gtp-kernel.c would impose such a constraint. gtp_kernel_create() is called
for every net-device, and gtp_kernel_tunnel_add is called for every PDP-context.

Actions #8

Updated by osmith 7 months ago

laforge wrote in #note-7:

On Tue, Jul 18, 2023 at 03:10:20PM +0000, osmith wrote:

However it is not possible currently to configure multiple APNs with the kernel module

I've now re-checked and couldn't find any mention of that constraint in the user manual, nor would
I see why code in gtp-kernel.c would impose such a constraint. gtp_kernel_create() is called
for every net-device, and gtp_kernel_tunnel_add is called for every PDP-context.

When creating the second APN:

tun.c:213 cannot create GTP tunnel device: Device or resource busy

EBUSY gets set here in the kernel: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/gtp.git/tree/drivers/net/gtp.c?id=4b215ddfdb88c8addfa2d775aa1014e7363313fc#n1498

As I understand it, the problem is that we pass the same gsn->fd0 and gsn->fd10 to gtp_kernel_create in lib/tun.c:tun_new().

Besides the problem with multiple APNs, I realized that I have been testing without the libgtpnl changes, and that these will need further changes in osmo-ggsn. I'm working on it and have set the patches to WIP.

full osmo-ggsn log

Actions #9

Updated by laforge 7 months ago

On Thu, Jul 20, 2023 at 01:35:30PM +0000, osmith wrote:

When creating the second APN:

> tun.c:213 cannot create GTP tunnel device: Device or resource busy
> 

that should only happen if the gtp device is actually busy.

As I understand it, the problem is that we pass the same gsn->fd0 and gsn->fd10 to gtp_kernel_create in lib/tun.c:tun_new().

Ah. Ok, that explains. The way how the kernel GTP driver works is that for each UDP socket there can only be one gtp-net-device. After all, the kernel and all of GTP-U know nothing about APNs. All they know is packets arriving, and TEID-to-IP address mappings.

This means, indeed, for every UDP socket, there can only be one APN configured. However, multiple different
UDP sockets can serve multiple APNs. The way how GTP-C vs GTP-U works, one can actually hand out a different GTP-U endpoint/socket/port for each PDP context that is being activated. So osmo-ggsn could create one different GTP-U socket for each APN, and then hand out the respective GTP-U IP address during PDP context activate.

As the above is not within the scope of this ticket, please
  • document the current constraint in the osmo-ggsn user manual (explaining it's not really a kernel GTP
    restriction but one of osmo-ggsn)
  • create an osmo-ggsn issue so we keep track of this constraint and hopefully fix it eventually.

Besides the problem with multiple APNs, I realized that I have been testing without the libgtpnl changes, and that these will need further changes in osmo-ggsn. I'm working on it and have set the patches to WIP.

yes, that part is the actual IPv6 support for kernel-gtp mode in osmo-ggsn. :)

Actions #10

Updated by osmith 7 months ago

  • Related to Bug #6106: OsmoGGSN attempts to use the same GTP-U socket for all APNs with gtpu-mode kernel-gtp added
Actions #11

Updated by osmith 7 months ago

laforge wrote in #note-9:

As the above is not within the scope of this ticket, please
  • document the current constraint in the osmo-ggsn user manual (explaining it's not really a kernel GTP
    restriction but one of osmo-ggsn)

-> https://gerrit.osmocom.org/c/osmo-ggsn/+/33865

  • create an osmo-ggsn issue so we keep track of this constraint and hopefully fix it eventually.

-> #6106

Actions #12

Updated by osmith 7 months ago

  • Blocked by Bug #6123: IPv4/IPv6 address family has to be the same for inner layer and outer layer added
Actions #13

Updated by osmith 7 months ago

  • Status changed from In Progress to Stalled
Actions #14

Updated by pablo 5 months ago

  • Related to Bug #1953: IPv6 support for outer (transport) IP layer missing added
Actions #15

Updated by osmith 5 months ago

  • Status changed from Stalled to In Progress
Actions #16

Updated by osmith 4 months ago

  • % Done changed from 30 to 50

WIP branch for osmo-ggsn: osmith/wip

See #1952 for discussion on related patches for libgtpnl and kernel.

Actions #17

Updated by osmith 4 months ago

  • Status changed from In Progress to Stalled
Actions #18

Updated by laforge 14 days ago

  • Priority changed from High to Urgent
Actions #19

Updated by osmith 12 days ago

  • Status changed from Stalled to In Progress
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)