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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 5 Feb 2022 17:34:12 +0100
From:   Harald Welte <>
To:     Marcin Szycik <>
Subject: Re: [RFC PATCH net-next v3 1/5] gtp: Allow to create GTP device
 without FDs

Hi Marcin, Wojciech,

thanks for the revised patch. In general it looks fine to me.

Do you have a public git tree with your patchset applied?  I'm asking as
we do have automatic testing in place at where I
just need to specify a remote git repo andit will build this kernel and
run the test suite.

Some minor remarks below, all not critical, just some thoughts.

It might make sense to mention in the commit log that this patch by itself
would create GTP-U without GTP ECHO capabilities, and that a subsequent
patch will address this.

> This patch allows to create GTP device without providing
> IFLA_GTP_FD0 and IFLA_GTP_FD1 arguments. If the user does not
> provide file handles to the sockets, then GTP module takes care
> of creating UDP sockets by itself. 

I'm wondering if we should make this more explicit, i.e. rather than
implicitly creating the kernel socket automagically, make this mode
explicit upon request by some netlink attribute.

> Sockets are created with the
> commonly known UDP ports used for GTP protocol (GTP0_PORT and

I'm wondering if there are use cases that need to operate on
non-standard ports.  The current module can be used that way (as the
socket is created in user space). If the "kernel socket mode" was
requested explicitly via netlink attribute, one could just as well
pass along the port number[s] this way.

- Harald Welte <>  
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Powered by blists - more mailing lists