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.
- 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.
- 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.