osmocom-net-gprs February 2021

osmocom-net-gprs@lists.osmocom.org

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

Osmocom CNI release 202102
by Pau Espin Pedrol 27 Feb '21

27 Feb '21

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/132 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(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

1 0

Very useful wireshark fix for NS / BSSGP decoding
by Harald Welte 14 Feb '21

14 Feb '21

In case anyone has been annoyed by this before: wireshark so far always showed _only_ the BSSGP decode in the Information column of a Gb interface pcap file, even if that BSSGP was contained in the "erroneous message" IE of a NS-STATUS message. This made it particularly difficult to spot NS-STATUS, and without custom coloring rules or search filters, a protocol trace would just look fine - except that in reality it isn't. I've now found out what's the proper method to resolve this and submitted a patch to wireshark, which was merged very quickly: https://gitlab.com/wireshark/wireshark/-/merge_requests/2081 After this change, the Information column in the packet list will show NS-STATUS with the human-redaable cause value for the reject, rather than displaying BSSGP as if nothing odd happened. 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 0

Question about OsmoGGSN project
by morteza ali Ahmadi 09 Feb '21

09 Feb '21

Hi, osmocom team members We have run OsmoGGSN project using the attached config file in this email and the following command: osmo-ggsn As you can see in the config file, we have set IP 127.0.0.2 for GGSN. After executing the above command, a tunnel named tun4 is created. To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow: sgsnemu -l 127.0.0.1 -r 127.0.0.2 After executing the above command, we see that 2 packets are sent from SGSN to GGSN. These packets are "Echo request" and "Create PDP context request" and GGSN responses to SGSN with the packets "Echo response" and "Create PDP context response". To test tun4, we send a GTP <DNS> packet containing an arbitrary query to GGSN and we see that this GTP <DNS> packet is received in Loopback (lo) interface and also, the DNS packet is received in tun4 interface. But there is no DNS response to our query neither in tun4 interface nor lo interface. A screenshot of the lo interface and tun4 interface in the wireshark is attached in this email (right is lo and left is tun4). How can we receive DNS responses to our DNS query? (Does tun4 require routing or something else?) -- *When there is much light, The shadow is deep...*

2 2

Question about libgtpnl
by morteza ali Ahmadi 04 Feb '21

04 Feb '21

Hi Osmocom team We have a basic question about libgtpnl (Linux Kernel GTP-U). We receive a lot of GTP <DNS> packets which are sent from MS to our HNB and from HNB to our SGSN (a screenshot is attached in this email). As you can see in the one of these packets in the attached image, our MS IP is 10.250.0.114 and our SGSN IP is 172.60.3.154. Also, our TEID is 100 which is set in RAB-Assignment Request sending from SGSN to HNB. In order to put these GTP packets in our GTP tunnel, we use libgtpnl and the two following commands: gtp-link add gtp1 gtp-tunnel add gtp1 v1 100 1 10.250.0.114 172.60.3.154 But when we monitor the gtp1 interface in the wireshark, there is no packet on this interface. Could you please help us to know the reason for this problem? (It is worth mentioning that after receiving these GTP <DNS> packets from MS to SGSN and using netstat, we see that Recv-Q (bytes in UDP port 2152 which are ready to read) is increased to a value more than 0) Best regards -- *When there is much light, The shadow is deep...*

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs February 2021