osmocom-net-gprs November 2017

osmocom-net-gprs@lists.osmocom.org

3 participants
4 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

Packets are not arrived at tunnel setup by libgtpnl
by congnt 24 Nov '17

24 Nov '17

Hi guys, I'm using libgtpnl tools (gtp-link, gtp-tunnel) to setup a tunnel in my local machines. I was able to setup gtp link to 2152 port as well as gtp tunnel. I have pre-recorded GTP packets with correct teid and IP address as well as chksum and port to send to 2152. However I can not see any packets in gtp link device when using tcpdump. By add some messages in gtp module, I notice that the function gtp1u_udp_encap_recv in gtp.c kernel file was never been called if I send packet with GTP headers. However, that function is called if I send normal UDP packet without GTP header. Note that I'm using Ubuntu 14.04 with kernel 4.8.0 lowlatency, the tunnel is on a VM created by Virtualbox using virtio network driver. Any suggestions on how to debug/solve this problem? Many thanks in advances. Best regards Cong.

2 2

libgtpnl migrated to gerrit
by Harald Welte 13 Nov '17

13 Nov '17

Hi all, FYI: I migrated libgtpnl (the kernel-GTP netlink interface helper library used by OpenGGSN and OsmoGGSN) to gerrit earlier today. This means direct pushes to git.osmocom.org no longer work and you will have to submit modifications via gerrit, as we do for all our other major repositories. I've also set up a gerrit build verification job via jenkins-job-builder and added a corresponding contrib/jenkins.sh script to it. The buildhosts now need libmnl-dev as build dependency installed. I added this to our current debian8 + debian9 build slaves and the wiki documentation about them. In other news: libgtpnl is already part of the network:osmocom:nightly and network:osmocom:latest feeds for some weeks. I intend to test kernel GTP support in osmo-ggsn soon and then change the package builds to include kernel-gtp support via libgtpnl by default. 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

Re: GPRS EXperiments
by Neels Hofmeyr 04 Nov '17

04 Nov '17

(BTW, for GPRS we use osmocom-net-gprs(a)lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@) On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote: > I've installed up to date versions of osmo-bts and osmo-pcu > on sysmobts 2050 hardware and it's working great! > Dynamic channels are really nice, with half rate TCH and AMR > working perfectly. Thanks for all that work! Good to hear that! > I configured pcodns1 in the ggsn to point to this DNS > server, AND I setup a port 53 redirect to catch quite a lot > of traffic from android that likes to just talk directly to > 8.8.8.8 anyway. Interesting, this sounds like it would make for a good wiki page on osmocom.org. > games. Such is the sad state of affairs on today's internet. > Fortunately, we have iptables and ip sets and we have AS > blocks assigned to certain bandwidth hungry corporations :-) So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;) > I have observed that if I initiate any data transfer from > the network side then the uplink is established. By the same > token, If I transfer a file from the network (http download > or some such), the same applies. The link stays active and > the IM chat session is very responsive alongside the file > transfer. Shortly after the file transfer completes, the > uplink is quiet again and the latency in the IM session > becomes a problem. It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding. So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through. I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well. Not sure how to configure the PDP context timeout, or whether we even can. Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea. Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways... Someone would need to fund that, or go ahead and try. ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs November 2017