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)