From pablo at netfilter.org Wed Aug 2 10:46:10 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed, 2 Aug 2017 12:46:10 +0200 Subject: [PATCH net 5/7] gtp: Initialize 64-bit per-cpu stats correctly In-Reply-To: <20170801191113.8754-6-f.fainelli@gmail.com> References: <20170801191113.8754-1-f.fainelli@gmail.com> <20170801191113.8754-6-f.fainelli@gmail.com> Message-ID: <20170802104610.GA2566@salvia> On Tue, Aug 01, 2017 at 12:11:10PM -0700, Florian Fainelli wrote: > On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a > lockdep splat indicating this seqcount is not correctly initialized, fix > that by using netdev_alloc_pcpu_stats() instead of an open coded > allocation. > > Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") > Signed-off-by: Florian Fainelli Acked-by: Pablo Neira Ayuso Thanks! From laforge at gnumonks.org Thu Aug 3 00:34:41 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 3 Aug 2017 02:34:41 +0200 Subject: OpenGGSN IPv6 PDP context support Message-ID: <20170803003441.gwwqc7pxjyc3s4pc@nataraja> Dear all, I've been busy all day (and night) implementing IPv6 PDP context support in OpenGGSN. The related code is currently in gerrit for review, you can also use the 'laforge/ipv6' branch of openggsn.git In terms of configuration, all you need to do is to specify IPv6 address + prefix as the 'net'. If you don't specify a 'dynip' config option, it will automatically use the network/prefix specified in 'net'. My minimalistic example config file for testing looks like this: debug fg listen 127.0.0.6 net 2001:780:44:2000:0:0:0:0/120 Which means it is listening for GTP on IPv4 (no IPv6 on the GTP side supported), and will create a tun device with the stated IPv6 address and a /120 netmask. Your GGSN is 2001:780:44:2000::1, and UEs will get addresses allocated from 2001:780:44:2000::2 onwards. It's important to configure your UE to actually request and IPv6 PDP context. If no v4/v6 is specified in the request, it will default to IPv4. If IPv4 is requested while having a v6 pool configured, OpenGGSN will reject the PDP Context Creation due to not being able to serve a v4 PDP context. I don't have immediate plans for supporting IPv6 on the outer (transport) layer for now. I also have no plans to support v4 and v6 from a single OpenGGSN at this time. It's quite easy to run two different OpenGGSN instances in parallel, on two different IPv4 addresses for the GTP side, and then use OsmoSGSN's PDP context routing to those different GGSNs. This way it is possible to have a v4 APN and a v6 APN without having to do any additional development right now. Architecturally, having multiple IP pools (and some for v4 and some for v6) is definitely possible, and should actually be easy. We just need to switch to a configuration mechanism that supports something like this, such as libosmovty. Once we have a VTY based configuration, it should be simple to operate multiple IP pools or multiple virtual APNs on one OpenGGSN. WARNING: The Linux Kernel GTP code does *not* support IPv6 user payload at this point. So if you want IPv6, you will need to use regular, old-fashioned userspace GTP-U in OpenGGSN for now. Controbutions are always welcome, of course! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Aug 31 06:46:43 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 31 Aug 2017 08:46:43 +0200 Subject: redmine e-mails broken from 08/26 through 08/31 Message-ID: <20170831064643.lyhdk5nhlahrsrsr@nataraja> Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Mon Aug 28 12:25:48 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 28 Aug 2017 14:25:48 +0200 Subject: RFC: OpenGGSN split/rename Message-ID: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de> Hi. With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository? Rationale: * would simplify docs for newcomers (it's not obvious that openggsn have to be built ahead of OsmoSGSN because of libgtp) * simplify release process (we can release libgtp independently of OpenGGSN, makes it easier to automate too) While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point. What do you think? -- Max Suraev 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 From laforge at gnumonks.org Thu Aug 31 11:56:46 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 31 Aug 2017 13:56:46 +0200 Subject: RFC: OpenGGSN split/rename In-Reply-To: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de> References: <34c1496e-8ce9-08ee-1b77-40fb3067fe93@sysmocom.de> Message-ID: <20170831115646.fy6rqhvyem5izjyc@nataraja> Hi Max, On Mon, Aug 28, 2017 at 02:25:48PM +0200, Max wrote: > With the ongoing split of OpenBSC into per-project repository, I wonder if we could > do the same to OpenGGSN and split libgtp into separate repository? Interesting proposal, I don't really have an existing opionion on it. > * would simplify docs for newcomers (it's not obvious that openggsn have to be built > ahead of OsmoSGSN because of libgtp) Not so sure if that would really simplify it. What would be a good idea is an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support" behavior. The configure script could also state that 'libgtp is missing... install it from openggsn' or the like. There are considerable infrastructural changes for libgtp pending: * the list/hashtable of PDP contexts / TEIDs is still global, and not per GSN * the outer (transport) layer is still IPv4 only * the kernel GTP-U support should become part of libgtp, not specific to OpenGGSN There is currently nobody funding related work or otherwise contributing to it, so this is just a wishlist without any clear target date for implementation. > * simplify release process (we can release libgtp independently of OpenGGSN, makes it > easier to automate too) I'm not sure if that's a simplification, though? > While at it and considering recent IPv6 support (and related config changes) it might > be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the > breaking point. The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom. Also, from an User point-of-view, it will be a different program. All recipes, manuals, wiki pages, etc. will need updates. But then, they will need updates due to the vty / config file changes anyway, so it might actually be better to have a new name since it "feels" completely different with VTY and related configuration than the old OpenGGSN. So in summary: * libgtp split: I'm not entirely sure if at all. If, then we should postpone the first release of that library until changes have been made. * rename: I'm more in favor again, but my opinion seems to change ever week ;) What do others think? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From f.fainelli at gmail.com Tue Aug 1 19:11:38 2017 From: f.fainelli at gmail.com (Florian Fainelli) Date: Tue, 01 Aug 2017 19:11:38 -0000 Subject: [PATCH net 5/7] gtp: Initialize 64-bit per-cpu stats correctly In-Reply-To: <20170801191113.8754-1-f.fainelli@gmail.com> References: <20170801191113.8754-1-f.fainelli@gmail.com> Message-ID: <20170801191113.8754-6-f.fainelli@gmail.com> On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that by using netdev_alloc_pcpu_stats() instead of an open coded allocation. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Florian Fainelli --- 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 1542e837fdfa..f38e32a7ec9c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -364,7 +364,7 @@ static int gtp_dev_init(struct net_device *dev) gtp->dev = dev; - dev->tstats = alloc_percpu(struct pcpu_sw_netstats); + dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats); if (!dev->tstats) return -ENOMEM; -- 2.9.3 From pablo at netfilter.org Wed Aug 2 12:52:58 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed, 02 Aug 2017 12:52:58 -0000 Subject: [PATCH net-next v1 1/3] gtp: refactor to support flow-based gtp encap and decap In-Reply-To: <1825145503.799984.1501485696720.JavaMail.zimbra@tpip.net> References: <20170713004455.3946570-1-ouyangj@fb.com> <20170713004455.3946570-2-ouyangj@fb.com> <1825145503.799984.1501485696720.JavaMail.zimbra@tpip.net> Message-ID: <20170802125246.GA4856@salvia> On Mon, Jul 31, 2017 at 09:21:36AM +0200, Andreas Schultz wrote: > Hi Jiannan, > > ----- On Jul 13, 2017, at 2:44 AM, Jiannan Ouyang ouyangj at fb.com wrote: > > [...] > > > -static int gtp_rx(struct pdp_ctx *pctx, struct sk_buff *skb, > > - unsigned int hdrlen, unsigned int role) > > +static int gtp_rx(struct gtp_dev *gtp, struct sk_buff *skb, > > + unsigned int hdrlen, struct sock *sk, > > + struct metadata_dst *tun_dst) > > Some time ago, there was an extensive discussion about the relation > of PDP context and network devices. You are basically reverting one > of the changes that was made in that context. I think it is wrong to > couple GTP devices and PDP context the way you do here (there are > people that disagree, though). > > The GTP network device of one of two structures owning the PDP context, > the other is the GTP socket. GTP network devices and GTP sockets should > be strictly separated. > > The GTP network device owns the IP given to the MS, handles mapping > IP's into GTP tunnels (peer GSN + TEIDs) and hands the resulting GTP > packets of to the GTP socket for sending. The GTP socket decaps the GTP > packet, find the right context and based on information therein passes > it to the GTP network device. > > By separating is that way, you can have MS with overlapping or colliding > IP's on the same GTP socket as long as they belong to different GTP network > devices. > > We had a length discussion about whether the above scenario makes sense. > I'm not sure if we reached a final verdict, but the 3GPP specifications > clearly permit such a setup. We need a netlink interface to retrieve GTP information accordingly, this includes a top-level APN object to represent what you need. That would allow to accomodate all usecases.