osmocom-net-gprs July 2017

osmocom-net-gprs@lists.osmocom.org

6 participants
3 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 31 Dec '25

31 Dec '25

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

[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

GTP in previous kernels
by fırat sönmez 10 Jul '17

10 Jul '17

Hi, I am currently working on building a GTP tunnel between two hosts. I used two virtual machines to implement GTP tunnel. The machines have the kernel 4.8 since GTP is in mainline. (I just did 'modprobe gtp') I setup the tunnel with libgtpnl tools. What I would like to do is that I want to have GTP module in a kernel 3.18. I did some google search and then I added the headers, libraries and the source code to the source code of 3.18 to compile all the kernel, but it didnt work. I am not experienced in kernel module programming or about the consequences compiling GTP in previous kernels which have different structural mechanisms than the 4.* versions. Is there any way to achieve this? If so, how could it be possible to get help from this community? Thanks all, Fırat

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs July 2017