osmocom-net-gprs March 2017

osmocom-net-gprs@lists.osmocom.org

11 participants
10 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

allow gtp tunnel updating in libgtpnl: gtp_add_tunnel()
by Jiannan Ouyang 29 Mar '17

29 Mar '17

Hi All, In current OAI implementation, we found that there are cases SPGW is out-of-sync with MME, because of the delete_session_request is not received by the SPGW because of some errors, however MME has cleared the state of that session. Then when the UE re-attaches, a new create_session_request is sent to SPGW; and because we try to allocate the same IP for the same IMSI (local change), the SPGW will result out in trying to update an existing GTP tunnel. According to http://lxr.free-electrons.com/source/drivers/net/gtp.c#L937 and https://github.com/RoadRunnr/osmo-ggsn/blob/master/libgtnl/src/gtp-genl.c#L…, the NLM_F_EXCL flag is used to prevent updating an existing tunnel. I’m is wondering what is the reason of preventing updating? While we are actively investigating sending delete_session_request properly, as temporary workaround, I’m thinking to recovery from the out-of-sync problem, we can allow the new GTP tunnel to overwrite the old one in libgtpnl. Your suggestions are welcomed. Thanks. Regards, -Jiannan

3 4

Updates on Osmocom Conference 2017
by Harald Welte 28 Mar '17

28 Mar '17

OsmoCon 2017 updates There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany. See http://osmocom.org/news/68 for the web version of this announcement. == Summary == Summary (for those too busy to read the full post): * Schedule of talks has been released http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule * Travel Grants available for participants who are otherwise unable to travel to Berlin: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants * Social Event details available, including menu: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent * April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available http://shop.sysmocom.de/products/ticket-for-osmocon-2017 == Details == === Schedule has been released === The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks. Please see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule for the schedule. As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks. === Travel Grants === We are happy to announce that we have received donations to permit for providing travel grants! This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant. For more details see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants and/or constact osmocon2017(a)sysmocom.de. === Social Event === Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees. See more details about it at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent -- - 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

[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
by Arnaud ZANETTI 27 Mar '17

27 Mar '17

Hi, building osmo-pcu on a raspberry Pi 3, I noticed a failure in make check: ## --------------------------------- ## ## osmo-pcu 0.2.896-0a8f test suite. ## ## --------------------------------- ## Regression tests 1: rlcmac ok 2: ts_alloc ok 3: tbf ok 4: bitcomp FAILED (testsuite.at:30) 5: edge ok 6: types ok 7: ms ok 8: llc ok 9: llist ok 10: codel ok 11: fn ok ## ------------- ## ## Test results. ## ## ------------- ## ERROR: All 11 tests were run, 1 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## The exact same test also fails on a raspberry Pi 2, with the same osmo-pcu and gcc versions but succeeds on an old Pentium4 Feel free to contact me if you need further informations. ----- Arnaud ZANETTI

2 1

[PATCH 0/2] libgtpnl patches
by Jonas Bonn 25 Mar '17

25 Mar '17

Here are two small patches for libgtpnl. They both apply to the laforge/sgsn-role branch (although patch 2/2 could be taken separately into the main branch, too). Patch 1/2 is a small fixup for a netlink parameter rename in a kernel patch. Patch 2/2 is a trivial include file addition to prevent some warnings. Jonas Bonn (2): Rename netlink attribute Provide declaration for struct in_addr include/libgtpnl/gtp.h | 1 + include/linux/gtp.h | 2 +- src/gtp-genl.c | 8 ++++---- 3 files changed, 6 insertions(+), 5 deletions(-) -- 2.9.3

2 3

git.osmocom.org cgit improvements
by Harald Welte 20 Mar '17

20 Mar '17

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. 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)

3 3

Re: [PATCH 1/1] gtp: support SGSN-side tunnels
by Harald Welte 16 Mar '17

16 Mar '17

Hi Pablo, On Wed, Mar 15, 2017 at 06:23:48PM +0100, Pablo Neira Ayuso wrote: > On Wed, Mar 15, 2017 at 05:39:16PM +0100, Harald Welte wrote: > > > > I would definitely like to see this move forward, particularly in order > > to test the GGSN-side code. > > Agreed. I've modified the patch slightly, see below (compile-tested, but not otherwise tested yet). Basically rename the flags attribute to 'role', expand the commit log and removed unrelated cosmetic changes. I've also prepared a corresponding change to libgtpnl into the laforge/sgsn-rol branch, see http://git.osmocom.org/libgtpnl/commit/?h=laforge/sgsn-role This is not yet tested in any way, but I'm planning to add some associated support to the command line tools and then give it some testing (both against the kernel GTP in GGSN mode, as well as an independent userspace GTP implementation). > It would be good if we provide a way to configure GTP via iproute2 for > testing purposes. I don't really care about which tool is used, as long as it is easily available [and FOSS, of course]. > We would need to create some dummy socket from > kernel too though so we don't need any userspace daemon for this > testing mode. I don't really like that latter idea. It sounds too much like a hack to me. But then, I don't have enough phantasy right now ti imagine how an actual implementation would look like. To me, it is perfectly fine to run a simple, small utility in userspace even for testing. Regards, Harald >From 63920950f9498069993def78e178bde85c174e0c Mon Sep 17 00:00:00 2001 From: Jonas Bonn <jonas(a)southpole.se> Date: Wed, 15 Mar 2017 17:52:28 +0100 Subject: [PATCH] gtp: support SGSN-side tunnels The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP contexts based on the incoming packets _destination_ address. For real-world use cases, this is sufficient, as the other side of a GTP tunnel is not in fact implemented by GTP, but by the protocol stacking of a mobile station / user equipment on the radio interface (like PDCP, SNDCP). However, if we want to simulate the mobile station, radio access network and SGSN (for example to test the GGSN side implementation), then we want to be identifying PDP contexts based on _source_ address. This patch adds a "role" attribute at GTP-link creation time to specify whether we behave like the GGSN or SGSN role of the tunnel; this attribute is then used to determine which part of the IP packet to use in determining the PDP context. Signed-off-by: Jonas Bonn <jonas(a)southpole.se> Signed-off-by: Harald Welte <laforge(a)gnumonks.org> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 99d3df788ce8..9aef4217f6e1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -71,6 +71,7 @@ struct gtp_dev { struct net_device *dev; + enum ifla_gtp_role role; unsigned int hash_size; struct hlist_head *tid_hash; struct hlist_head *addr_hash; @@ -149,8 +150,8 @@ static struct pdp_ctx *ipv4_pdp_find(struct gtp_dev *gtp, __be32 ms_addr) return NULL; } -static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { struct iphdr *iph; @@ -159,18 +160,21 @@ static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, iph = (struct iphdr *)(skb->data + hdrlen); - return iph->saddr == pctx->ms_addr_ip4.s_addr; + if (role == GTP_ROLE_SGSN) + return iph->daddr == pctx->ms_addr_ip4.s_addr; + else + return iph->saddr == pctx->ms_addr_ip4.s_addr; } /* Check if the inner IP source address in this packet is assigned to any * existing mobile subscriber. */ -static bool gtp_check_src_ms(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { switch (ntohs(skb->protocol)) { case ETH_P_IP: - return gtp_check_src_ms_ipv4(skb, pctx, hdrlen); + return gtp_check_ms_ipv4(skb, pctx, hdrlen, role); } return false; } @@ -204,7 +208,7 @@ static int gtp0_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -261,7 +265,7 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -490,7 +494,11 @@ static int gtp_build_skb_ip4(struct sk_buff *skb, struct net_device *dev, * Prepend PDP header with TEI/TID from PDP ctx. */ iph = ip_hdr(skb); - pctx = ipv4_pdp_find(gtp, iph->daddr); + if (gtp->role == GTP_ROLE_SGSN) + pctx = ipv4_pdp_find(gtp, iph->saddr); + else + pctx = ipv4_pdp_find(gtp, iph->daddr); + if (!pctx) { netdev_dbg(dev, "no PDP ctx found for %pI4, skip\n", &iph->daddr); @@ -665,12 +673,26 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, int hashsize, err, fd0, fd1; struct gtp_dev *gtp; struct gtp_net *gn; + unsigned int role; + + /* The default role is GGSN, and for backwards compatibility + * reasons, the lack of a IFLA_GTP_ROLE IE means that we're + * operating in GGSN role. */ + if (data[IFLA_GTP_ROLE]) { + role = nla_get_u32(data[IFLA_GTP_ROLE]); + if (role != GTP_ROLE_GGSN && + role != GTP_ROLE_SGSN) + return -EINVAL; + } else + role = GTP_ROLE_GGSN; if (!data[IFLA_GTP_FD0] || !data[IFLA_GTP_FD1]) return -EINVAL; gtp = netdev_priv(dev); + gtp->role = role; + fd0 = nla_get_u32(data[IFLA_GTP_FD0]); fd1 = nla_get_u32(data[IFLA_GTP_FD1]); @@ -722,6 +744,7 @@ static const struct nla_policy gtp_policy[IFLA_GTP_MAX + 1] = { [IFLA_GTP_FD0] = { .type = NLA_U32 }, [IFLA_GTP_FD1] = { .type = NLA_U32 }, [IFLA_GTP_PDP_HASHSIZE] = { .type = NLA_U32 }, + [IFLA_GTP_ROLE] = { .type = NLA_U32 }, }; static int gtp_validate(struct nlattr *tb[], struct nlattr *data[]) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index 72a04a0e8cce..79037cca6b51 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -19,7 +19,7 @@ enum gtp_attrs { GTPA_LINK, GTPA_VERSION, GTPA_TID, /* for GTPv0 only */ - GTPA_SGSN_ADDRESS, + GTPA_SGSN_ADDRESS, /* Remote GSN, either SGSN or GGSN */ GTPA_MS_ADDRESS, GTPA_FLOW, GTPA_NET_NS_FD, diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h index 6b13e591abc9..de7bea223749 100644 --- a/include/uapi/linux/if_link.h +++ b/include/uapi/linux/if_link.h @@ -536,11 +536,18 @@ enum { #define IFLA_PPP_MAX (__IFLA_PPP_MAX - 1) /* GTP section */ + +enum ifla_gtp_role { + GTP_ROLE_GGSN = 0, + GTP_ROLE_SGSN, +}; + enum { IFLA_GTP_UNSPEC, IFLA_GTP_FD0, IFLA_GTP_FD1, IFLA_GTP_PDP_HASHSIZE, + IFLA_GTP_ROLE, __IFLA_GTP_MAX, }; #define IFLA_GTP_MAX (__IFLA_GTP_MAX - 1) -- 2.11.0 -- - Harald Welte <laforge(a)netfilter.org> http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie

2 2

[PATCH net-next 0/4] gtp: support multiple APN's per GTP endpoint
by Andreas Schultz 15 Mar '17

15 Mar '17

Support multiple APN's per GTP endpoint and as an additional benefit support multiple GTP sockets per GTP entity. Use case multiple APN's: ------------------------ In 3GPP a APN is control path construct. When mappend into the data path, it mean that UE IP's can be source from independended IP networks with overlaping IP ranges. 3GPP, TS 29.061 version 13.6.0 Release 13, Section 11.3 describes this as: > 2. each private network manages its own addressing. In general this will > result in different private networks having overlapping address ranges. > A logically separate connection (e.g. an IP in IP tunnel or layer 2 > virtual circuit) is used between the GGSN/P-GW and each private network. > In this case the IP address alone is not necessarily unique. The pair > of values, Access Point Name (APN) and IPv4 address and/or IPv6 prefixes, > is unique. To support such a setup, each APN is mapped to a Linux network device. VRF-Lite, network namespaces or other mechanismns can the be used to realize the full separation of the per APN IP networks. Use case multiple GTP sockets per GTP entity: --------------------------------------------- A GTP entity like a PGW can use multiple GTP sockets for: * separate IPv4 and IPv6 transport endpoints * support multiple reference points in separated IP networks, e.g. have Gn/Gp/S5/S8 in a GRX attaches network and S2a/S2b in another private network Especially the S2a/S2b separation is an important scenario. The networks use for roaming and non roaming attachment (Gn/Gp/S5/S8 reference points) are usually different from the connection for trusted and untrusted WiFi access (S2a/S2b). Will the GTP transport networks are separated, it is still desirable to terminated the tunnels in the same GTP entity to ensure uninterrupted IP connectivity during 3G/LTE to/from WiFi handover. Implementation: --------------- APN's are a control path construct, the identification of the associated network device need therefore to be bound to be tunnel endpoint identifier. This series moves the hash for the incoming tunnel endpoint identifiers into the socket to support multiple network devices per GTP socket. It the adds a method of enabling the GTP encapsulation on a socket without having to bound the socket to a network device and finally allows to specify a GTP socket per PDP context. API impact: ----------- This is probably the most problematic part of this series... The removeal of the TEID form the netdevice also means that the gtp genl API for retriving tunnel information and removing tunnels needs to be adjusted. Before this change it was possible to change a GTP tunnel using the gtp netdevice id and the teid. The teid is no longer unique per gtp netdevice. After this change it has to be either the netdevice and MS IP or the GTP socket and teid. Fortunatly, libgtpnl has always populated the Link Id, TEID, GSN Peer IP and MS IP. The library interface has ensured that all information that is mandatory after this change is guaranteed to be present. The only project that doesn't use libgtpnl (OpenAir-CN) is also populating all of those values. The API change will therefore not break any existing userspace applications. -- Andreas Schultz (4): gtp: move TEID hash to per socket structure gtp: add genl cmd to enable GTP encapsulation on UDP socket gtp: add support to select a GTP socket during PDP context creation Extend Kernel GTP-U tunneling documentation Documentation/networking/gtp.txt | 103 ++++++++++++++- drivers/net/gtp.c | 263 ++++++++++++++++++++++++++++----------- include/uapi/linux/gtp.h | 4 + 3 files changed, 292 insertions(+), 78 deletions(-) -- 2.10.2

4 14

[PATCH net-next v5 0/7] gtp: misc improvements
by Andreas Schultz 14 Mar '17

14 Mar '17

Hi Pablo, This is a resent of last series that missed the merge window. There are no changes compared to v4. v4: Compared to v3 it contains mostly smallish naming and spelling fixes. It also drops the documentation patch, Harald did a better job with the documentation and the some things I described do not yet match the implementation. I'll readd the relevant parts with a follow up series. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlapping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support, coming a follow up series). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. v4->v5: * resent for new merge window v3->v4: * drop the documentation patch * spelling fixes * pass nlattr instead of genl_info into gtp_find_dev, makes the code slightly more compact and readable v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (7): gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context drivers/net/gtp.c | 543 +++++++++++++++++++++++++++--------------------------- 1 file changed, 269 insertions(+), 274 deletions(-) -- 2.10.2

4 12

SMS over GPRS
by Christian Wilkinson 11 Mar '17

11 Mar '17

Hi! According to the OsmoSGSN wiki, SMS delivery over GPRS is currently a TODO item. I was wondering about the current state of this feature, and if there is any work in progress that could be built upon. Is there an estimate of the amount of dev work required to contribute this feature to the project? Thanks, Christian

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs March 2017