<div dir="ltr"><div dir="ltr">Hi,<br><br>> It would be great if you could share your GGSN code base with the community,<br>> like we share the kernel GTP-U and all of Osmocom with you.<br><br>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.<br><br>> it is very likely your lack of sending any GTP echo responses.<br>Yes, this is what I was saying.<br>Look, for GTP-C, I am listening in Port 2123. it's free for my userspace program.<br>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.<br><br>> You manage all your UDP sockets.<br>> your application is responsible for receiving and responding to any GTP-U packets there.<br>As I said, I am using Erlang as a userspace program.<br>And when I create a tunnel, I "just" send a basic command exec to the Linux by open_port like this:<br><br> 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,<br> ==> it gives me a string something like "gtp-tunnel add gt1 v1 123456 654321 192.168.1.82 172.23.0.1"<br> then, I execute it<br> io:fwrite("~p~n", [osexec:cmd(Gtp_Tunnel_add)])<br><br>The same when deleting the tunnel.<br>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.<br><br><br>> I don't really understand what you are trying to say here. OsmoSGSN is<br>> a "real" SGSN and it speaks exactly the same 3GPP protocols like other SGSNs.<br>> The kernel GTP-U plane doesn't care about what your SGSN is, or what your GGSN is.<br>Allow me to give a short explanation.<br>Between 2 lInux, I create some pair like this:<br>Linux A: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2<br>Linux B: gtp-tunnel add gtpb v1 100 200 172.99.0.1 172.0.0.1<br>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<br><br>But with my linux ggsn and a real SGSN:<br>Linux A ggsn: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2<br>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.<br>Because when the MS wants to send traffic, e.g browse to youtube, the packet from MS has the IP of youtube as destination.<br>So, I assume it needs to match to the "ms_addr" parameter in some kind of gtp-tunnel parameter at SGSN side.<br>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.<br>like this:<br>"gtp-tunnel add gtpa v1 200 100 ms_addr sgsn_addr"<br>And with this, is my tunnel UP? Because as I said, the SGSN is saying he detects that the path on GGSN was down.<br><br>Best Regards,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 21 août 2020 à 02:00, Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Aug 20, 2020 at 12:49:20PM +0300, Papa Tana wrote:<br>
> - upon receipt of my creade_pdp_context_response accepted, the SGSN now<br>
> try to establish a Tunnel with the given TEID towards my GGSN<br>
> - but I cannot see anything on my GTPU-side in ggsn, apart of several<br>
> echo-request message from SGSN<br>
> - Sure, SGSN try to test connectivity to my ggsn GTPU by using<br>
> echo-request, but no response<br>
> - I don't know maybe because of no response, or because of SGSN alert me<br>
> with an error gtpu-sm-cause-update-ggsn-path-failure, the SGSN decide to<br>
> send a delete request<br>
<br>
it is very likely your lack of sending any GTP echo responses.<br>
<br>
> - 1) At GTP-C, I can implement all messages(echo-response,<br>
> create-response, delete-response) but at GTPU-side, as the port is used by<br>
> libgtpnl, I cannot implement an echo-response at all <br>
<br>
Why would you make such an assumption? The UDP socket for GTPU is opened<br>
by your application in userspace. You own it. The fact that you passed into<br>
libgtpnl as an argument to gtp_dev_create() doesn't mean you shouldn't use that<br>
socket. To the contrary, your application is responsible for receiving and<br>
responding to any GTP-U packets there.<br>
<br>
> ==> So, do libgtpnl is<br>
> supposed to answer or not to an echo-response received from a SGSN at<br>
> GTPU-level?<br>
<br>
libgtpnl is (as the 'nl' in the name applies) a library to help you use the netlink<br>
interface to configure the GTP-U infrastructure in the kernel. It doesn't ever<br>
implement or touch any GTP-U itself.<br>
<br>
> - 2) When I tried a Linux-to-Linux setup, it worked because I specified<br>
> the ms_addr and sgsn_addr in the 02 Linux Host.<br>
> But as I cannot configure anything about the tunnel at SGSN-side(done<br>
> automatically by SGSN), I can only create the tunnel at ggsn-side thanks to<br>
> my user space program, by passing the TEID and ms_addr input to libgtpnl.<br>
> Does it mean that libgtpnl only complies with OpenGGSN, ergw, and<br>
> OpenAirInterface but not intended to ber used with a real SGSN?<br>
<br>
I don't really understand what you are trying to say here. OsmoSGSN is<br>
a "real" SGSN and it speaks excatly the same 3GPP protocols like other SGSNs.<br>
The kernel GTP-U plane doesn't care about what your SGSN is, or what your GGSN is.<br>
<br>
-- <br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</blockquote></div></div>