GTP tunnel seems to exist, but No encapsulation when using libgtpnl

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.

Papa Tana papa.tana101 at gmail.com
Fri Aug 21 06:53:34 UTC 2020


Hi,

> It would be great if you could share your GGSN code base with the
community,
> like we share the kernel GTP-U and all of Osmocom with you.

Sure, as for now, I' am still in the early stage, and the code is pretty
dirty as I just wanted to make it work first. I'm not really a true
programmer, but I was amazed by OSMOGGSN years ago, and I wanted to
understand how it is working, so I learned Erlang by June 2020, and this is
my first real project. It's a draft yet.

> it is very likely your lack of sending any GTP echo responses.
Yes, this is what I was saying.
Look, for GTP-C, I am listening in Port 2123. it's free for my userspace
program.
But for GTP-U, I was trying to listen in port 2152 several times, and it
yields an error that I cannot listen on it, port 2152 is already used.

> You manage all your UDP sockets.
> your application is responsible for receiving and responding to any GTP-U
packets there.
As I said, I am using Erlang as a userspace program.
And when I create a tunnel, I "just" send a basic command exec to the Linux
by open_port like this:

Gtp_Tunnel_add = "gtp-tunnel add gtp1 v1 " ++ integer_to_list(Tei_u_peer)
++ " "++ integer_to_list(Tei_u_local) ++" " ++ Pdp_ms_address ++ " " ++
Sgsn_addr,
==> it gives me a string something like "gtp-tunnel add gt1 v1 123456
654321 192.168.1.82 172.23.0.1"
then, I execute it
io:fwrite("~p~n", [osexec:cmd(Gtp_Tunnel_add)])

The same when deleting the tunnel.
So I don't have any idea on how to listen to 2152 as my Erlang program is
forbidden to listen on it when libgtpnl is invoked.


> I don't really understand what you are trying to say here.  OsmoSGSN is
> a "real" SGSN and it speaks exactly the same 3GPP protocols like other
SGSNs.
> The kernel GTP-U plane doesn't care about what your SGSN is, or what your
GGSN is.
Allow me to give a short explanation.
Between 2 lInux, I create some pair like this:
Linux A: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2
Linux B: gtp-tunnel add gtpb v1 100 200 172.99.0.1 172.0.0.1
Now, when Linux A ping 172.99.0.1, packet is encapsulated with
sgsn_addr_src = 172.0.0.1 and sgsn_addr_dest = 172.0.0.2

But with my linux ggsn and a real SGSN:
Linux A ggsn: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2
Real SGSN: Is the SGSN doing something like this? gtp-tunnel add gtpb v1
100 200 **172.99.0.1**** 172.0.0.1 <<< this part, I was wondering.
Because when the MS wants to send traffic, e.g browse to youtube, the
packet from MS has the IP of youtube as destination.
So, I assume it needs to match to the "ms_addr" parameter in some kind of
gtp-tunnel parameter at SGSN side.
I know SGSN is not using libgtpnl, but I want to make sure that is it okay
if I just create the gtp-tunnel on ggsn side, and I don't care about what
SGSN is doing.
like this:
"gtp-tunnel add gtpa v1 200 100 ms_addr sgsn_addr"
And with this, is my tunnel UP? Because as I said, the SGSN is saying he
detects that the path on GGSN was down.

Best Regards,

Le ven. 21 août 2020 à 02:00, Harald Welte <laforge at gnumonks.org> a écrit :

> On Thu, Aug 20, 2020 at 12:49:20PM +0300, Papa Tana wrote:
> >  - upon receipt of my creade_pdp_context_response accepted, the SGSN now
> > try to establish a Tunnel with the given TEID towards my GGSN
> >  - but I cannot see anything on my GTPU-side in ggsn, apart of several
> > echo-request message from SGSN
> >  - Sure, SGSN try to test connectivity to my ggsn GTPU by using
> > echo-request, but no response
> >  - I don't know maybe because of no response, or because of SGSN alert me
> > with an error gtpu-sm-cause-update-ggsn-path-failure, the SGSN decide to
> > send a delete request
>
> it is very likely your lack of sending any GTP echo responses.
>
> >  - 1) At GTP-C, I can implement all messages(echo-response,
> > create-response, delete-response) but at GTPU-side, as the port is used
> by
> > libgtpnl, I cannot implement an echo-response at all
>
> Why would you make such an assumption?  The UDP socket for GTPU is opened
> by your application in userspace.  You own it.  The fact that you passed
> into
> libgtpnl as an argument to gtp_dev_create() doesn't mean you shouldn't use
> that
> socket.  To the contrary, your application is responsible for receiving and
> responding to any GTP-U packets there.
>
> > ==> So, do libgtpnl is
> > supposed to answer or not to an echo-response received from a SGSN at
> > GTPU-level?
>
> libgtpnl is (as the 'nl' in the name applies) a library to help you use
> the netlink
> interface to configure the GTP-U infrastructure in the kernel.  It doesn't
> ever
> implement or touch any GTP-U itself.
>
> >  - 2) When I tried a Linux-to-Linux setup, it worked because I specified
> > the ms_addr and sgsn_addr in the 02 Linux Host.
> >  But as I cannot configure anything about the tunnel at SGSN-side(done
> > automatically by SGSN), I can only create the tunnel at ggsn-side thanks
> to
> > my user space program, by passing the TEID and ms_addr input to libgtpnl.
> > Does it mean that libgtpnl only complies with OpenGGSN, ergw, and
> > OpenAirInterface but not intended to ber used with a real SGSN?
>
> I don't really understand what you are trying to say here.  OsmoSGSN is
> a "real" SGSN and it speaks excatly the same 3GPP protocols like other
> SGSNs.
> The kernel GTP-U plane doesn't care about what your SGSN is, or what your
> GGSN is.
>
> --
> - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20200821/809a2b3e/attachment.htm>


More information about the osmocom-net-gprs mailing list