osmocom-net-gprs October 2021

osmocom-net-gprs@lists.osmocom.org

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

TTCN-3 tests for MME
by Mirko Kovacevic 29 Oct '21

29 Oct '21

Hi, Osmonians, I don't know where to write for MME TTCN-3, so I chose to write to it closet relative - SGSN. I was trying to do slight modification to TTCN-3 code, modifing S1AP_Templates.ttcn. I embedded enodeb name for all tests with new protoc-IE = id-eNBname : ################################## template (value) S1AP_PDU ts_S1AP_SetupReq(template (value) Global_ENB_ID p_global_ENB_ID, template (value) SupportedTAs p_supportedTAs, template (value) PagingDRX p_pagingDRXs) := { initiatingMessage := { procedureCode := id_S1Setup, criticality := reject, value_ := { S1SetupRequest := { protocolIEs := { { id := S1AP_Constants.id_Global_ENB_ID, criticality := ignore, value_ := { Global_ENB_ID := p_global_ENB_ID } }, { id := S1AP_Constants.id_SupportedTAs, criticality := reject, value_ := {SupportedTAs := p_supportedTAs} }, { id := S1AP_Constants.id_eNBname,//id-eNBname criticality := ignore, value_ := {ENBname := "OsmoEnodeb"} } /* HACK: work around nextepc bug , { id := S1AP_Constants.id_pagingDRX, criticality := ignore, value_ := {PagingDRX := p_pagingDRXs} } */ } } } } } ######################## Code compiles, but PDU is not encoded well. I attached Wireshark preview. Can you help me with this issue ? -- Puno pozdrava, Mirko Kovacevic

3 6

Osmocom redmine upgrade / Let me know if something broke
by Harald Welte 27 Oct '21

27 Oct '21

Dear Osmocom community, today we finally upgraded our redmine installation from the unmaintained 3.4.x to the latest 4.2.3. The upgrade had been overdue for years, but today we (actually, Kevin) finally managed to find out how to make the openid_provider plugin to work with modern rails 5.x. In any case, I'm just informing you in case there is some unexpected fallout. I've verified that at least the following appears working: * logging into redmine * openid authentication from gerrit.osmocom.org (also after logout/relogin) * graphviz rendering * mscgen rendering There could however still be unexpected problems, particularly in features such as * e-mail notifications from redmine * updating redmine issues via e-mail * git integration ("Closes: OS#xxxx") If you run into any troubles, pleas report to https://osmocom.org/projects/osmocom-servers or if that also fails, feel free to send e-mails. 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

[PATCH net-next] gtp: use skb_dst_update_pmtu_no_confirm() instead of direct call
by Gyeongun Kang 06 Oct '21

06 Oct '21

skb_dst_update_pmtu_no_confirm() is a just wrapper function of ->update_pmtu(). So, it doesn't change logic Signed-off-by: Gyeongun Kang <kyeongun15(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 30e0a10595a1..24e5c54d06c1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -539,7 +539,7 @@ static int gtp_build_skb_ip4(struct sk_buff *skb, struct net_device *dev, mtu = dst_mtu(&rt->dst); } - rt->dst.ops->update_pmtu(&rt->dst, NULL, skb, mtu, false); + skb_dst_update_pmtu_no_confirm(skb, mtu); if (!skb_is_gso(skb) && (iph->frag_off & htons(IP_DF)) && mtu < ntohs(iph->tot_len)) { -- 2.25.1

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs October 2021