lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 11 Feb 2022 10:27:14 +0000 From: "Drewek, Wojciech" <wojciech.drewek@...el.com> To: Harald Welte <laforge@...ocom.org> CC: Marcin Szycik <marcin.szycik@...ux.intel.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "michal.swiatkowski@...ux.intel.com" <michal.swiatkowski@...ux.intel.com>, "davem@...emloft.net" <davem@...emloft.net>, "kuba@...nel.org" <kuba@...nel.org>, "pablo@...filter.org" <pablo@...filter.org>, "osmocom-net-gprs@...ts.osmocom.org" <osmocom-net-gprs@...ts.osmocom.org> Subject: RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response Hi Harald, > -----Original Message----- > From: Harald Welte <laforge@...ocom.org> > Sent: piÄ…tek, 11 lutego 2022 10:16 > To: Drewek, Wojciech <wojciech.drewek@...el.com> > Cc: Marcin Szycik <marcin.szycik@...ux.intel.com>; netdev@...r.kernel.org; michal.swiatkowski@...ux.intel.com; > davem@...emloft.net; kuba@...nel.org; pablo@...filter.org; osmocom-net-gprs@...ts.osmocom.org > Subject: Re: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response > > Hi Wojciech, > > On Tue, Feb 08, 2022 at 02:12:33PM +0000, Drewek, Wojciech wrote: > > > Remember, GTP-U uses different IP addresses and also typically completely > > > different hosts/systems, so having GTP-C connectivity between two GSN > > > doesn't say anything about the GTP-U path. > > > > Two approaches come to mind. > > The first one assumes that peers are stored in kernel as PDP contexts in > > gtp_dev (tid_hash and addr_hash). Then we could enable a watchdog > > that could in regular intervals (defined by the user) send echo requests > > to all peers. > > Interesting proposal. However, it raises the next question of what to do if > the path is deemed to be lost (N out of M recent echo requests unanswered)? It > would have to notify the userspace daemon (control plane) via a netlink event > or the like. So at that point you need to implement some special processing in > that userspace daemon... > > > In the second one user could trigger echo request from userspace > > (using new genl cmd) at any time. However this approach would require that > > some userspace daemon would implement triggering this command. > > I think this is the better approach. It keeps a lot of logic like timeouts, > frequency of transmission, determining when a path is considered dead, ... out > of the kernel, where it doesn't need to be. > > > What do you think? > > As both approaches require some support from the userspace control plane instance, > I would argue that the second proposal is superior. > > Regards, > Harald I agree that second option is better so I'll start to implementing it. Regards, Wojtek > > -- > - Harald Welte <laforge@...ocom.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)
Powered by blists - more mailing lists