From firatssonmez at gmail.com  Fri May  5 10:29:18 2017
From: firatssonmez at gmail.com (=?UTF-8?B?ZsSxcmF0IHPDtm5tZXo=?=)
Date: Fri, 5 May 2017 13:29:18 +0300
Subject: kernel-to-kernel gtp implementation
Message-ID: <CAA5f=PhiWNKzP_GvbGubJ0MsS1OAmkGp8KG8X3ym2KHuRJAfCw@mail.gmail.com>

Hi,

I am currently working in a project where I was asked to implement a GTP
tunnel from client to company servers.

I have read through osmocom pages and tried to implement the simple network
structure. I have seen from Basic testing of openGGSN page:

"     test GTP-U interoperability of the kernel with at least one other
implementation, not just kernel-to-kernel (which currently is not supported
in the kernel, as it only implements the GGSN/P-GW role)   "

I would not like to implement openGGSN but just linux-kernel-gtp-u
implementation between two kernels.

To achieve kernel-to-kernel implementation, I found sgsn patch on the
internet:

https://patchwork.ozlabs.org/patch/739408/


and there is already a kernel-gtp-U in osmocom.


So, my basic network structure is below.

[image: Sat?r i?i resim 2]


I would like make a tunnel between sgsn and ggsn. I have used libgtpnl
tools to create link and then tunnel. I have added a default gateway GTP
interface to route table on sgsn side, but the packets cannot reach ggsn
side.

Is there any detailed explanation for a simple bidirectional tunnel setup.
If so, it would be so nice to know about.

Thank you for all your efforts,
F?rat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170505/d8e8a35d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 15221 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170505/d8e8a35d/attachment.png>

From laforge at gnumonks.org  Fri May  5 13:41:21 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 May 2017 15:41:21 +0200
Subject: kernel-to-kernel gtp implementation
In-Reply-To: <CAA5f=PhiWNKzP_GvbGubJ0MsS1OAmkGp8KG8X3ym2KHuRJAfCw@mail.gmail.com>
References: <CAA5f=PhiWNKzP_GvbGubJ0MsS1OAmkGp8KG8X3ym2KHuRJAfCw@mail.gmail.com>
Message-ID: <20170505134121.ogam63cbqpzaqb2v@nataraja>

Hi,

the configuration you use is not a typical GTP use case, and nothing
supported in mainline Linux so far.


On Fri, May 05, 2017 at 01:29:18PM +0300, f?rat s?nmez wrote:
> To achieve kernel-to-kernel implementation, I found sgsn patch on the
> internet:
> 
> https://patchwork.ozlabs.org/patch/739408/

I think you would have to ask the author of that patch, as your question
relates to a feature specifically introduced by the patch.  He is
probably the only one ever having used that feature so far.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Tue May  9 12:12:42 2017
From: holger at freyther.de (Holger Freyther)
Date: Tue, 9 May 2017 14:12:42 +0200
Subject: Removing FCS from SNDCP packages
Message-ID: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>

Hi,

I see that while adding decompression support dexter has fixed a bug in
the sndcp code. Before the GTP-U frame would include the LLC FCS and now
we do this:

	npdu_len = (msg->data + msg->len) - npdu - 3;

What I wonder (and the commit message didn't say is) was the fragment
part handled as well. The calculation is:

        /* make sure to subtract length of SNDCP header from 'len' */
        rc = defrag_enqueue(sne, suh->seg_nr, data, len - (data - hdr)); 

and len is passed in from the TLV struct in gprs_llc_rcvmsg. I think the
fragmented case is working okay.

Shall we try to unify the length calculation to rely on the local "len"
variable instead of checking msg->data+msg->len?


cheers
	holger


From nhofmeyr at sysmocom.de  Wed May 10 12:09:21 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 10 May 2017 14:09:21 +0200
Subject: Removing FCS from SNDCP packages
In-Reply-To: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>
References: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>
Message-ID: <20170510120921.GB22770@my.box>

(dexter is currently on vacation, back next week)

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170510/2f96b74d/attachment.bin>

From holger at freyther.de  Wed May 10 14:03:34 2017
From: holger at freyther.de (Holger Freyther)
Date: Wed, 10 May 2017 16:03:34 +0200
Subject: Removing FCS from SNDCP packages
In-Reply-To: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>
References: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>
Message-ID: <626DD78D-6B31-432B-9A51-49479DD1CA61@freyther.de>


> On 9. May 2017, at 14:12, Holger Freyther <holger at freyther.de> wrote:
> 
> 	npdu_len = (msg->data + msg->len) - npdu - 3;
> 
> What I wonder (and the commit message didn't say is) was the fragment
> part handled as well. The calculation is:
> 
>        /* make sure to subtract length of SNDCP header from 'len' */
>        rc = defrag_enqueue(sne, suh->seg_nr, data, len - (data - hdr)); 
> 
> and len is passed in from the TLV struct in gprs_llc_rcvmsg. I think the
> fragmented case is working okay.
> 
> Shall we try to unify the length calculation to rely on the local "len"
> variable instead of checking msg->data+msg->len?

Or to make it a bit more clear. The -3 assumes that something is beyond
the LLC IE. I think instead of assuming that we should use the IE len
(instead of msg->len). We already do that in the fragmented case.

holger


From hwelte at sysmocom.de  Tue May 16 16:03:51 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Tue, 16 May 2017 18:03:51 +0200
Subject: Removing FCS from SNDCP packages
In-Reply-To: <626DD78D-6B31-432B-9A51-49479DD1CA61@freyther.de>
References: <96DFE2AE-273F-469D-8AA5-B9C757E9381D@freyther.de>
 <626DD78D-6B31-432B-9A51-49479DD1CA61@freyther.de>
Message-ID: <20170516160351.ulv6t6zmuqarxv47@nataraja>

Hi Holger,

On Wed, May 10, 2017 at 04:03:34PM +0200, Holger Freyther wrote:

> Or to make it a bit more clear. The -3 assumes that something is beyond
> the LLC IE. I think instead of assuming that we should use the IE len
> (instead of msg->len). We already do that in the fragmented case.

seems very reasonable to me.

-- 
- Harald Welte <hwelte at sysmocom.de>             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 garsilva at embeddedor.com  Tue May 23 23:18:37 2017
From: garsilva at embeddedor.com (Gustavo A. R. Silva)
Date: Tue, 23 May 2017 18:18:37 -0500
Subject: [PATCH] net: fix potential null pointer dereference
Message-ID: <20170523231837.GA9364@embeddedgus>

Add null check to avoid a potential null pointer dereference.

Addresses-Coverity-ID: 1408831
Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.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 4fea1b3..7b652bb 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -873,7 +873,7 @@ static struct gtp_dev *gtp_find_dev(struct net *src_net, struct nlattr *nla[])
 
 	/* Check if there's an existing gtpX device to configure */
 	dev = dev_get_by_index_rcu(net, nla_get_u32(nla[GTPA_LINK]));
-	if (dev->netdev_ops == &gtp_netdev_ops)
+	if (dev && dev->netdev_ops == &gtp_netdev_ops)
 		gtp = netdev_priv(dev);
 
 	put_net(net);
-- 
2.5.0



From pablo at netfilter.org  Wed May 24 09:29:30 2017
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Wed, 24 May 2017 11:29:30 +0200
Subject: [PATCH] net: fix potential null pointer dereference
In-Reply-To: <20170523231837.GA9364@embeddedgus>
References: <20170523231837.GA9364@embeddedgus>
Message-ID: <20170524092930.GA12351@salvia>

On Tue, May 23, 2017 at 06:18:37PM -0500, Gustavo A. R. Silva wrote:
> Add null check to avoid a potential null pointer dereference.
> 
> Addresses-Coverity-ID: 1408831
> Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>

Acked-by: Pablo Neira Ayuso <pablo at netfilter.org>

This is a fix for the net.git tree BTW.


From davem at davemloft.net  Thu May 25 16:54:28 2017
From: davem at davemloft.net (David Miller)
Date: Thu, 25 May 2017 12:54:28 -0400 (EDT)
Subject: [PATCH] net: fix potential null pointer dereference
In-Reply-To: <20170523231837.GA9364@embeddedgus>
References: <20170523231837.GA9364@embeddedgus>
Message-ID: <20170525.125428.743684247535321797.davem@davemloft.net>

From: "Gustavo A. R. Silva" <garsilva at embeddedor.com>
Date: Tue, 23 May 2017 18:18:37 -0500

> Add null check to avoid a potential null pointer dereference.
> 
> Addresses-Coverity-ID: 1408831
> Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>

Applied, thank you.