From: Harald Welte <laforge@gnumonks.org>
To: Marcin Szycik <marcin.szycik@linux.intel.com>
Cc: netdev@vger.kernel.org, michal.swiatkowski@linux.intel.com,
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
Date: Thu, 27 Jan 2022 15:40:52 +0100 [thread overview]
Message-ID: <YfKu9NwF7/RKsMbb@nataraja> (raw)
In-Reply-To: <20220127125725.125915-1-marcin.szycik@linux.intel.com>
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)
next prev parent reply other threads:[~2022-01-27 14:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 12:57 [RFC PATCH net-next v2 1/5] gtp: Allow to create GTP device without FDs Marcin Szycik
2022-01-27 14:40 ` Harald Welte [this message]
2022-01-27 19:14 ` Drewek, Wojciech
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfKu9NwF7/RKsMbb@nataraja \
--to=laforge@gnumonks.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=marcin.szycik@linux.intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=osmocom-net-gprs@lists.osmocom.org \
--cc=pablo@netfilter.org \
--cc=wojciech.drewek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox