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
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)
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
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
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)
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
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
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
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