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