Feature #6096
openadd support for kernel-GTP IPv6
80%
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
Updated by osmith 9 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.
Updated by laforge 9 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).
Updated by laforge 9 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.
Updated by osmith 9 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.
Updated by laforge 9 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.
- 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. :)
Updated by osmith 9 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
Updated by osmith about 1 month ago
- % Done changed from 50 to 80
- osmo-ggsn has been adjusted, patches are in master
- libgtpnl has been adjusted, patches are in master
- kernel has been adjusted (#1952), and patches are being upstreamed
Temporary TTCN3 testsuite job with the kernel patches:
https://jenkins.osmocom.org/jenkins/job/ttcn3-ggsn-test-kernel-pablo-gtp/
