osmocom-net-gprs December 2018

osmocom-net-gprs@lists.osmocom.org

4 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

OsmoDevCon 2019 registration
by Harald Welte 31 Dec '18

31 Dec '18

Dear fellow Osmocom developers, I'm a bit surprised to notice that not more people have signed up for OsmoDevCon 2019. I guess it was mostly an oversight when the date was originally announced, and not a lack of interest? ;) All details about the event are available at the related wiki page at: https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2019. 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

Question about basic usage of GTP kernel module
by Michał Siuda 07 Dec '18

07 Dec '18

Hi, I'm trying to build a simple node that would encap/decap between IP and GTP in the user plane. For this I have been using gtp-link and gtp-tunnel tools of the libgtpnl, but with no luck so far. Could anyone please review my setup and let me know what I'm doing wrong? Topology: node1 - DUT, I would like to be able to send a ping from this node such that it is encapsulated into GTP tunnel towards node2. 2 interfaces: - ens6 - represents interface towards MS, has address 20.1.1.1/24 - ens7 - represents interface towards GGSN, has address 10.1.1.1/24 node2 Just a single interface towards node1, address 10.1.1.2/24 Test: On node2, I'm following these steps: - creating a GTP device: # ./gtp-link add gtp-u - adding a GTP tunnel: # ./gtp-tunnel add gtp-u v1 20 10 20.1.1.1 10.1.1.2 # ./gtp-tunnel list version 1 tei 20/10 ms_addr 20.1.1.1 sgsn_addr 10.1.1.2 - adding a route to an address representing APN to use the GTP device: # ip route add 8.8.8.8 src 20.1.1.1 dev gtp-u - Trying to ping 8.8.8.8 Result: I was expecting to see ECMP packets to 8.8.8.8 to be sent out via ens7 towards node2 and encapsulated in GTP. However, I can only see that these packets appear on the gtp-u interface, but are not forwarded. Looking at interface stats on gtp-u, I can see that the ping hits "tx_error" counter. Is there anything I'm missing here? Are any parameters wrong? Or am I misunderstanding the function of the GTP-U kernel support entirely? Any help would be appreciated. Thanks, Michael

1 0

Can you tell me how to compile and install libgtpnl?
by luo 06 Dec '18

06 Dec '18

hello,Please forgive my childishness,Can you tell me how to compile and install libgtpnl?thanks I saw that you wrote the libgtpnl project on github, but there is no readme above.

2 1

[BUG][OSMO-PCU][OSMO-SGSN] GPRS and EGPRS attach procedure is not working with Kirin Modem phones
by Bipin Jaiswal 06 Dec '18

06 Dec '18

Hi, We are using Honor 7X mobile phone with Huawei Kirin modem and observed that GPRS and EGPRS attach is not working with Huawei Kirin Modem phones. There is no issue observed from OSMO-PCU. it seems either Huawei Kirin modem issue or OSMO-SGSN issue. Please check below analysis for this issue. 1- UE send attach request with IMSI and invalid MCC and MNC to SGSN. 2- SGSN send Identity Request with IMEI to UE. 3- UE responded Identity Response with IMEI to SGSN. 4- SGSN sends ATTACH ACCEPT message to SGSN with new PMTSI but UE is not responding ATTACH COMPLETE message to SGSN and resend ATTACH REQUEST message to SGSN. 5- SO SGSN re transmit ATTACH ACCEPT message to UE and after max number of re transmission , SGSN is release UE MM context. It seems that UE is not accepting ATTACH ACCEPT message. We also observed that Huawei Kirin UE is sending wrong LLC data to SGSN. UE had set more bit in RLC LME header and send invalid LLC data with 0x2B. So OSMO-PCU had forward this data to SGSN because more bit is set and SGSN is complaining LLC error for this LLC data. Please look into this issue or let us know if we have fix for this issue. Thanks, Bipin Jaiswal

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs December 2018