osmocom-net-gprs August 2017

osmocom-net-gprs@lists.osmocom.org

4 participants
6 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 01 Jan '26

01 Jan '26

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)

4 5

RFC: OpenGGSN split/rename
by Max 03 Sep '17

03 Sep '17

Hi. With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository? Rationale: * would simplify docs for newcomers (it's not obvious that openggsn have to be built ahead of OsmoSGSN because of libgtp) * simplify release process (we can release libgtp independently of OpenGGSN, makes it easier to automate too) While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point. What do you think? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 5

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - 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)

1 0

OpenGGSN IPv6 PDP context support
by Harald Welte 03 Aug '17

03 Aug '17

Dear all, I've been busy all day (and night) implementing IPv6 PDP context support in OpenGGSN. The related code is currently in gerrit for review, you can also use the 'laforge/ipv6' branch of openggsn.git In terms of configuration, all you need to do is to specify IPv6 address + prefix as the 'net'. If you don't specify a 'dynip' config option, it will automatically use the network/prefix specified in 'net'. My minimalistic example config file for testing looks like this: debug fg listen 127.0.0.6 net 2001:780:44:2000:0:0:0:0/120 Which means it is listening for GTP on IPv4 (no IPv6 on the GTP side supported), and will create a tun device with the stated IPv6 address and a /120 netmask. Your GGSN is 2001:780:44:2000::1, and UEs will get addresses allocated from 2001:780:44:2000::2 onwards. It's important to configure your UE to actually request and IPv6 PDP context. If no v4/v6 is specified in the request, it will default to IPv4. If IPv4 is requested while having a v6 pool configured, OpenGGSN will reject the PDP Context Creation due to not being able to serve a v4 PDP context. I don't have immediate plans for supporting IPv6 on the outer (transport) layer for now. I also have no plans to support v4 and v6 from a single OpenGGSN at this time. It's quite easy to run two different OpenGGSN instances in parallel, on two different IPv4 addresses for the GTP side, and then use OsmoSGSN's PDP context routing to those different GGSNs. This way it is possible to have a v4 APN and a v6 APN without having to do any additional development right now. Architecturally, having multiple IP pools (and some for v4 and some for v6) is definitely possible, and should actually be easy. We just need to switch to a configuration mechanism that supports something like this, such as libosmovty. Once we have a VTY based configuration, it should be simple to operate multiple IP pools or multiple virtual APNs on one OpenGGSN. WARNING: The Linux Kernel GTP code does *not* support IPv6 user payload at this point. So if you want IPv6, you will need to use regular, old-fashioned userspace GTP-U in OpenGGSN for now. Controbutions are always welcome, of course! 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)

1 0

[PATCH net-next v1 0/3] Flow Based GTP Tunneling
by Jiannan Ouyang 02 Aug '17

02 Aug '17

This patch series augmented the existing GTP module to support flow based GTP tunneling and modified the openvswitch datapath to support the GTP vport type. A flow based GTP net device enables that, 1) on the RX path, the outer (IP/UDP/GTP) header information could to be stored in the metadata_dst struct, and embedded into the skb. 2) on the TX path, packets are encapsulated following instructions in the metadata_dst field of the skb. A flow based GTP net device can be integrated with Open vSwitch, which allows SDN controllers to program GTP tunnels via Open vSwitch. Open vSwitch changes are based on patch set [PATCH] Add GTP vport based on upstream datapath Example usage with OVS: ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ ofport_request=2 type=gtp option:remote_ip=flow options:key=flow ovs-ofctl add-flow br0 "in_port=2,tun_src=192.168.60.141,tun_id=123, \ actions=set_field:02:00:00:00:00:00->eth_src, \ set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL" ovs-ofctl add-flow br0 \ "in_port=LOCAL,actions=set_tunnel:888, \ set_field:192.168.60.141->tun_dst,2" arp -s 10.1.1.122 02:00:00:00:00:00 Jiannan Ouyang (3): gtp: refactor to support flow-based gtp encap and decap gtp: Support creating flow-based gtp net_device openvswitch: Add GPRS Tunnel Protocol (GTP) vport support drivers/net/gtp.c | 375 ++++++++++++++++++++++++++++++++------- include/net/gtp.h | 8 + include/uapi/linux/openvswitch.h | 1 + net/openvswitch/Kconfig | 10 ++ net/openvswitch/Makefile | 1 + net/openvswitch/vport-gtp.c | 144 +++++++++++++++ 6 files changed, 475 insertions(+), 64 deletions(-) create mode 100644 net/openvswitch/vport-gtp.c -- 2.9.3

6 16

[PATCH net 5/7] gtp: Initialize 64-bit per-cpu stats correctly
by Florian Fainelli 02 Aug '17

02 Aug '17

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that by using netdev_alloc_pcpu_stats() instead of an open coded allocation. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 1542e837fdfa..f38e32a7ec9c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -364,7 +364,7 @@ static int gtp_dev_init(struct net_device *dev) gtp->dev = dev; - dev->tstats = alloc_percpu(struct pcpu_sw_netstats); + dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats); if (!dev->tstats) return -ENOMEM; -- 2.9.3

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs August 2017