Hi Harald,
Thanks for the response, I'll take a look on how GTP-U ECHO works and I'll try to implement it.
Regards, Wojtek
-----Original Message----- From: Harald Welte laforge@gnumonks.org Sent: czwartek, 27 stycznia 2022 15:41 To: Marcin Szycik marcin.szycik@linux.intel.com Cc: netdev@vger.kernel.org; michal.swiatkowski@linux.intel.com; Drewek, Wojciech wojciech.drewek@intel.com; davem@davemloft.net; kuba@kernel.org; pablo@netfilter.org; osmocom-net-gprs@lists.osmocom.org Subject: Re: [RFC PATCH net-next v2 1/5] gtp: Allow to create GTP device without FDs
Hi Wojciech,
thanks for your contribution, I think in general it is a good idea.
However, I do not think this can be merged, as the resulting system would not be possible to use in a spec-compliant way.
Currently, when the user wants to create GTP device, he has to provide file handles to the sockets created in userspace (IFLA_GTP_FD0, IFLA_GTP_FD1). This behaviour is not ideal, considering the option of adding support for GTP device creation through ip link. Ip link application is not a good place to create such sockets.
The GTP kernel module in its past and current form only handles G-PDU packets and not any other packets. So it relies on always having a user space process [the one with the socket you want to make optional to handle other frames, such as GTP ECHO.
So if you apply your patch, you will end up creating a GTP-U instance which does not respond to echo requests, which is in violation of 3GPP specs and which will create problems in production.
So if you want to make this optional, you'd also have to implement GTP-U ECHO handling in the kernel, and require that in-kernel handling to be enabled when creating a GTP device without the socket file descriptors.
Regards, Harald
--
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)