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,