osmocom-net-gprs July 2020

osmocom-net-gprs@lists.osmocom.org

5 participants
5 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

Getting "Operation Not Permitted" When Running gtp-link
by Donal Crowley 20 Jul '20

20 Jul '20

Hi all, I am running an opensource 5G Core however I cannot get my UPF up and running ads the GTP links and tunnels I am trying to create are failing with “Operation Not Permitted”. I’ll recompile again to run through GDB but would really like to hear back if you guys have seen this before on Ubuntu 18.04 (Kernel > 5) Any help would be appreciated Donal Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

1 0

Osmocom scheduled outage on *2020-07-19 9am CEST*
by Harald Welte 19 Jul '20

19 Jul '20

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

Network is unreachable error for GTP interface
by avatli＠itu.edu.tr 18 Jul '20

18 Jul '20

Hi I'm trying to build a setup by using GTP module and libgtpnl tools on Centos 7 but I haven't been successful yet. Worse, I don't know how to debug the problem. I also stopped firewall and iptables. How can I debug/solve, I will be very glad if you help. dmesg or system messages show show nothing. Why is GTP interface (link) is unreachable. Thanks in advance - Volkan $ modinfo gtp filename: /lib/modules/5.7.7-1.el7.elrepo.x86_64/kernel/drivers/net/gtp.ko alias: net-pf-16-proto-16-family-gtp alias: rtnl-link-gtp description: Interface driver for GTP encapsulated traffic author: Harald Welte <hwelte(a)sysmocom.de> license: GPL srcversion: 191407DA5399304D93D62C7 depends: udp_tunnel retpoline: Y intree: Y name: gtp vermagic: 5.7.7-1.el7.elrepo.x86_64 SMP mod_unload modversions $ modinfo udp_tunnel filename: /lib/modules/5.7.7-1.el7.elrepo.x86_64/kernel/net/ipv4/udp_tunnel.ko license: GPL srcversion: 0A315BA6124B0664F4D23FB depends: retpoline: Y intree: Y name: udp_tunnel vermagic: 5.7.7-1.el7.elrepo.x86_64 SMP mod_unload modversions $ ip addr add 172.0.0.1/24 dev enp9s0 $ ip addr add 172.99.0.1/32 dev lo $ ./gtp-link add gtp1 WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes. $ ./gtp-tunnel add gtp1 v1 200 100 172.99.0.2 172.0.0.2 $ ip route add 172.99.0.2/32 dev gtp1 $ ./gtp-tunnel list version 1 tei 200/100 ms_addr 172.99.0.2 sgsn_addr 172.0.0.2 $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 172.99.0.1/32 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 7: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 08:35:71:ab:54:5f brd ff:ff:ff:ff:ff:ff inet 172.0.0.1/24 scope global enp9s0 valid_lft forever preferred_lft forever 8: gtp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 0 qdisc noqueue state UNKNOWN group default qlen 1000 link/none $ ip route default via 192.168.1.1 dev enp2s0 proto static metric 100 172.0.0.0/24 dev enp9s0 proto kernel scope link src 172.0.0.1 172.99.0.2 dev gtp1 scope link $ ping 172.99.0.2 PING 172.99.0.2 (172.99.0.2) 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable

3 3

Basic testing for Kernel GTP-U is not up to date
by avatli＠itu.edu.tr 17 Jul '20

17 Jul '20

Hello I tried to follow the steps in the basic testing below but it is not up-to-date https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing To make the setup work, I execute the GGSN on the host by using osmo-ggsn/doc/examples/osmo-ggsn.cfg. I changed the "gtp bind-ip" to 172.31.1.1, "ip prefix dynamic" to 192.168.71.0/24, "ip ifconfig" to 192.168.71.0/24 and then execute the emulated SGSN inside the sgsn namespace (ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2 --defaultroute --createif). In this case; GGSN can create PDP Context successful but there is not any GTP tunnel. How can I get the up-to-date version of this document? or how can I run the basic testing steps? Thanks in advance. - Volkan

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs July 2020