From papa.tana101 at gmail.com Fri Aug 7 13:41:22 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Fri, 7 Aug 2020 16:41:22 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl Message-ID: Hi All, This is my first post, I have a similar problem to the topic "Network is unreachable error for GTP interface". I followed all instructions, installed all needed dependencies, upgrade my kernel version to 4.9.0-6 as stated in https://osmocom.org/projects/openggsn/wiki/Kernel_GTP Unfortunately, no GTP T-PDU encapsulation for my packets. ## Tunnel listing is OK root at routeurA:/home/bob/libgtpnl/tools# ./gtp-tunnel list version 1 tei 200/100 ms_addr 172.23.10.163 sgsn_addr 10.11.12.14 ## I have upgraded my Kernel version to 4.9.0-6 as stated in https://osmocom.org/projects/openggsn/wiki/Kernel_GTP At the time of writing (2018-04-26) of this wiki, below listed distributions have support of GTP kernels : Debian Debian 9 "stretch" (kernel 4.9.0-6) root at routeurA:/home/bob/libgtpnl/tools# uname -r 4.9.0-6-amd64 ## GTP module root at routeurA:/home/bob/libgtpnl/tools# lsmod | grep gtp gtp 28672 0 udp_tunnel 16384 1 gtp ## ping remote ms_addr is not ok root at routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163 PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data. ^C --- 172.23.10.163 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms ## remove the route using "gtpa" device root at routeurA:/home/bob/libgtpnl/tools# ip route del 172.23.10.163/32 dev gtpa ## add new route using normal interface root at routeurA:/home/bob/libgtpnl/tools# ip route add 172.23.10.163/32 via 10.11.12.14 ## ping is OK root at routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163 PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data. 64 bytes from 172.23.10.163: icmp_seq=1 ttl=64 time=0.592 ms 64 bytes from 172.23.10.163: icmp_seq=2 ttl=64 time=0.713 ms ## remove again the route root at routeurA:/home/bob/libgtpnl/tools# ip route del 172.23.10.163/32 ## switch it to "gtpa" device root at routeurA:/home/bob/libgtpnl/tools# ip route add 172.23.10.163/32 dev gtpa root at routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163 PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data. ^C ## tcpdump shows ICMP between the 2 ms_addr, no encapsulation at all Am I missing something somewhere? FYI, I'm not using openggsn or ergw, I have developped my small userspace GTP-C ready, but I'm stuck at GTP-U side. Thanks in advance, Best Regards, From papa.tana101 at gmail.com Sat Aug 8 07:59:24 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Sat, 8 Aug 2020 10:59:24 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: Message-ID: It is working now. Very simple and stupid mistake from my side at network namespace configuration. Sorry for that! Thanks! Best Regards, From laforge at osmocom.org Mon Aug 10 19:58:54 2020 From: laforge at osmocom.org (Harald Welte) Date: Mon, 10 Aug 2020 21:58:54 +0200 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: Message-ID: <20200810195854.GK2338189@nataraja> Hi Papa, On Sat, Aug 08, 2020 at 10:59:24AM +0300, Papa Tana wrote: > It is working now. > Very simple and stupid mistake from my side at network namespace configuration. I'm very happy to hear it's working successfully. Sometimes I start to doubt if there are problems in the codebase, but the fact that you report you got it to work is a relief in that regard :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From papa.tana101 at gmail.com Thu Aug 20 09:49:20 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Thu, 20 Aug 2020 12:49:20 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: <20200810195854.GK2338189@nataraja> References: <20200810195854.GK2338189@nataraja> Message-ID: Hi, After successfully making libgtpnl works between 02 Linux Host, now I am in the step of connecting one Linux Host to a real live SGSN this morning. I don't have any particular issue at GTP-C side: - the Mobile Station registered on 3G network, requests one activate PDP context to the SGSN - the SGSN sends to my ggsn a create PDP context - my ggsn accepts it, and answers with all the needed information, such as MS_Address, DNS Address 1, DNS address 2, IP of GGSN-C, IP of GGSN-U, TEID Control Plane, TEID user plane, .... everything should be OK. - 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 So I have 02 questions please: - 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 ==> So, do libgtpnl is supposed to answer or not to an echo-response received from a SGSN at GTPU-level? - 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? Thanks for clarifying me, Best Regards, Le lun. 10 ao?t 2020 ? 23:00, Harald Welte a ?crit : > Hi Papa, > > On Sat, Aug 08, 2020 at 10:59:24AM +0300, Papa Tana wrote: > > It is working now. > > Very simple and stupid mistake from my side at network namespace > configuration. > > I'm very happy to hear it's working successfully. Sometimes I start to > doubt > if there are problems in the codebase, but the fact that you report you > got it > to work is a relief in that regard :) > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From papa.tana101 at gmail.com Thu Aug 20 16:05:58 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Thu, 20 Aug 2020 19:05:58 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> Message-ID: Well, After debugging, it is more likely to have some bug in my code because finally, it works after several scenario, but for some reason I don't understand so far, after a moment, the SGSN requests to delete the pdp context. So, I was connected with a real sim card for around 1 minute, great! But I still need a clarification about what to do about echo-response at GTP-U because I can only handle echo-response at GTP-C because my ggsn listen in 2123, but I cannot add any message at all like echo-response in 2152 because libgtpnl manage it. Best Regards, Le jeu. 20 ao?t 2020 ? 12:49, Papa Tana a ?crit : > Hi, > > After successfully making libgtpnl works between 02 Linux Host, now I am > in the step of connecting one Linux Host to a real live SGSN this morning. > > I don't have any particular issue at GTP-C side: > > - the Mobile Station registered on 3G network, requests one activate PDP > context to the SGSN > - the SGSN sends to my ggsn a create PDP context > - my ggsn accepts it, and answers with all the needed information, such > as MS_Address, DNS Address 1, DNS address 2, IP of GGSN-C, IP of GGSN-U, > TEID Control Plane, TEID user plane, .... everything should be OK. > - 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 > > So I have 02 questions please: > > - 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 ==> So, do libgtpnl is > supposed to answer or not to an echo-response received from a SGSN at > GTPU-level? > > - 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? > > Thanks for clarifying me, > Best Regards, > > > Le lun. 10 ao?t 2020 ? 23:00, Harald Welte a ?crit : > >> Hi Papa, >> >> On Sat, Aug 08, 2020 at 10:59:24AM +0300, Papa Tana wrote: >> > It is working now. >> > Very simple and stupid mistake from my side at network namespace >> configuration. >> >> I'm very happy to hear it's working successfully. Sometimes I start to >> doubt >> if there are problems in the codebase, but the fact that you report you >> got it >> to work is a relief in that regard :) >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at osmocom.org Thu Aug 20 22:59:01 2020 From: laforge at osmocom.org (Harald Welte) Date: Fri, 21 Aug 2020 00:59:01 +0200 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> Message-ID: <20200820225901.GM3544863@nataraja> Hi, On Thu, Aug 20, 2020 at 07:05:58PM +0300, Papa Tana wrote: > listen in 2123, but I cannot add any message at all like echo-response in > 2152 because libgtpnl manage it. libgtpnl does not manage your UDP socket at all. It manages a netlink socket to the kernel, which is used to create + delete objects in kernel space. You manage all your UDP sockets. I'm not sure where this misconception is coming from. It would be great if you could share your GGSN code base with the community, like we share the kernel GTP-U and all of Osmocom with you. As can be seen in gtp1u_udp_encap_recv(), ther eare multiple situations where GTP-U packets are passed to the socket and not handled in the kernel: * any GTP-U version != 1 * any GTP message types != GTP_TPDU * any GTP messages for which the kernel doesn't know the TID * any GTP messages whose inner IPv4 destination address doesn't match the TID All of those messsages must be implemented in your userspace program, using the very socket your application has created. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Aug 20 22:51:45 2020 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Aug 2020 00:51:45 +0200 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> Message-ID: <20200820225145.GL3544863@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From papa.tana101 at gmail.com Fri Aug 21 06:53:34 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Fri, 21 Aug 2020 09:53:34 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: <20200820225145.GL3544863@nataraja> References: <20200810195854.GK2338189@nataraja> <20200820225145.GL3544863@nataraja> Message-ID: Hi, > It would be great if you could share your GGSN code base with the community, > like we share the kernel GTP-U and all of Osmocom with you. Sure, as for now, I' am still in the early stage, and the code is pretty dirty as I just wanted to make it work first. I'm not really a true programmer, but I was amazed by OSMOGGSN years ago, and I wanted to understand how it is working, so I learned Erlang by June 2020, and this is my first real project. It's a draft yet. > it is very likely your lack of sending any GTP echo responses. Yes, this is what I was saying. Look, for GTP-C, I am listening in Port 2123. it's free for my userspace program. But for GTP-U, I was trying to listen in port 2152 several times, and it yields an error that I cannot listen on it, port 2152 is already used. > You manage all your UDP sockets. > your application is responsible for receiving and responding to any GTP-U packets there. As I said, I am using Erlang as a userspace program. And when I create a tunnel, I "just" send a basic command exec to the Linux by open_port like this: Gtp_Tunnel_add = "gtp-tunnel add gtp1 v1 " ++ integer_to_list(Tei_u_peer) ++ " "++ integer_to_list(Tei_u_local) ++" " ++ Pdp_ms_address ++ " " ++ Sgsn_addr, ==> it gives me a string something like "gtp-tunnel add gt1 v1 123456 654321 192.168.1.82 172.23.0.1" then, I execute it io:fwrite("~p~n", [osexec:cmd(Gtp_Tunnel_add)]) The same when deleting the tunnel. So I don't have any idea on how to listen to 2152 as my Erlang program is forbidden to listen on it when libgtpnl is invoked. > I don't really understand what you are trying to say here. OsmoSGSN is > a "real" SGSN and it speaks exactly 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. Allow me to give a short explanation. Between 2 lInux, I create some pair like this: Linux A: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2 Linux B: gtp-tunnel add gtpb v1 100 200 172.99.0.1 172.0.0.1 Now, when Linux A ping 172.99.0.1, packet is encapsulated with sgsn_addr_src = 172.0.0.1 and sgsn_addr_dest = 172.0.0.2 But with my linux ggsn and a real SGSN: Linux A ggsn: gtp-tunnel add gtpa v1 200 100 172.99.0.2 172.0.0.2 Real SGSN: Is the SGSN doing something like this? gtp-tunnel add gtpb v1 100 200 **172.99.0.1**** 172.0.0.1 <<< this part, I was wondering. Because when the MS wants to send traffic, e.g browse to youtube, the packet from MS has the IP of youtube as destination. So, I assume it needs to match to the "ms_addr" parameter in some kind of gtp-tunnel parameter at SGSN side. I know SGSN is not using libgtpnl, but I want to make sure that is it okay if I just create the gtp-tunnel on ggsn side, and I don't care about what SGSN is doing. like this: "gtp-tunnel add gtpa v1 200 100 ms_addr sgsn_addr" And with this, is my tunnel UP? Because as I said, the SGSN is saying he detects that the path on GGSN was down. Best Regards, Le ven. 21 ao?t 2020 ? 02:00, Harald Welte a ?crit : > 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 > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Aug 21 12:34:38 2020 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Aug 2020 14:34:38 +0200 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> <20200820225145.GL3544863@nataraja> Message-ID: <20200821123438.GO3544863@nataraja> On Fri, Aug 21, 2020 at 09:53:34AM +0300, Papa Tana wrote: > But for GTP-U, I was trying to listen in port 2152 several times, and it > yields an error that I cannot listen on it, port 2152 is already used. You cannot do that, sorry. > > You manage all your UDP sockets. > > your application is responsible for receiving and responding to any GTP-U > packets there. > As I said, I am using Erlang as a userspace program. > And when I create a tunnel, I "just" send a basic command exec to the Linux > by open_port like this: This will obviously not work. You need to manage the socket from your program. IF it's erlang, you either have to speak netlink directly from within Erlang, or you need to add some native functions for calling libgtpnl. > So I don't have any idea on how to listen to 2152 as my Erlang program is > forbidden to listen on it when libgtpnl is invoked. You are asking for the impossible. You need to open the socket from within your program. You cannot crate a second socket for what you are trying to do. At least earlier versions of ergw had support for the kernel GTP-U plane, why not simply use that code? They created https://github.com/travelping/gen_netlink to talk netlink from erlang, including gtpnl support. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From papa.tana101 at gmail.com Fri Aug 21 13:57:03 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Fri, 21 Aug 2020 16:57:03 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: <20200821123438.GO3544863@nataraja> References: <20200810195854.GK2338189@nataraja> <20200820225145.GL3544863@nataraja> <20200821123438.GO3544863@nataraja> Message-ID: > At least earlier versions of ergw had support for the kernel GTP-U plane, why > not simply use that code? My experience with erlang is very limited so far, that's why I was attracted with libgtpnl, because I was able to create a GTP tunnel by invoking only 2 lines # ./gtp-link add # ./gtp-tunnel add > They created https://github.com/travelping/gen_netlink to talk netlink from > erlang, including gtpnl support. Yes, I saw it. but even trying to build it from tetrapak, I have made some search but I'm struggling: # tetrapak build check (don't even know what is tetrapak :-) ) The creators of these libraries already answer some questions from me in the public erlang mailing list, but about general erlang related questions. I didn't find any public mailing list to these libraries, so I gave up. > You cannot do that, sorry. > This will obviously not work. > You need to manage the socket from your program. > You are asking for the impossible. I totally agree with you but I've got some idea this afternoon as a workaround. I think I can forward the echo-request that I received on my network interface (owned by gtpnl at GTP-U) to my Erlang program by using some Linux helper like # tcpdump # replay the traffic by tcpreplay to another interface owned by my Erlang program # or I can Write them to a Linux named pipe fifo, and get it from Erlang By this way, I would be able to craft an echo-response for GTP-U I think. Those steps are not related to libgtpnl anymore, so would be off-topic. But Clarifications regarding libgtpnl is very clear for me now. Thank you, P.S: I will update here if this echo-response at GTP-U side from my erlang works for me. Have a nice day. Le ven. 21 ao?t 2020 ? 15:40, Harald Welte a ?crit : > On Fri, Aug 21, 2020 at 09:53:34AM +0300, Papa Tana wrote: > > But for GTP-U, I was trying to listen in port 2152 several times, and it > > yields an error that I cannot listen on it, port 2152 is already used. > > You cannot do that, sorry. > > > > You manage all your UDP sockets. > > > your application is responsible for receiving and responding to any > GTP-U > > packets there. > > As I said, I am using Erlang as a userspace program. > > And when I create a tunnel, I "just" send a basic command exec to the > Linux > > by open_port like this: > > This will obviously not work. You need to manage the socket from your > program. > > IF it's erlang, you either have to speak netlink directly from within > Erlang, > or you need to add some native functions for calling libgtpnl. > > > So I don't have any idea on how to listen to 2152 as my Erlang program is > > forbidden to listen on it when libgtpnl is invoked. > > You are asking for the impossible. You need to open the socket from > within your > program. You cannot crate a second socket for what you are trying to do. > > At least earlier versions of ergw had support for the kernel GTP-U plane, > why not simply use that code? > > They created https://github.com/travelping/gen_netlink > to talk netlink from erlang, including gtpnl support. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From papa.tana101 at gmail.com Fri Aug 21 17:04:54 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Fri, 21 Aug 2020 20:04:54 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> <20200820225145.GL3544863@nataraja> <20200821123438.GO3544863@nataraja> Message-ID: > As can be seen in gtp1u_udp_encap_recv(), there are multiple situations where > GTP-U packets are passed to the socket and not handled in the kernel: > * any GTP-U version != 1 > * any GTP message types != GTP_TPDU > * any GTP messages for which the kernel doesn't know the TID > * any GTP messages whose inner IPv4 destination address doesn't match the TID Humm, this answer seems very interesting for me. While trying to make my ggsn work using some Linux helper as I said previously, on the other hand, I want to try netlink now after your very clear explanation. I found that tetrapak is just a building tool, so I can use gen_netlink because I understand the concept now. I will ask them on the mailing list, but "in a more general way" (not erlang only point of view), I have read on wikipedia and it's similar to Unix Socket, this I am familiar with, I can manage them in userspace. I understood that netlink is a bit similar, not using filename but PID instead (IPC: Inter Process Communication), and *sounds even more great because thanks to netlink, I would be able to discuss to the kernel level from user space!!!!* Even though the source code of libgtpnl is open, I have 0 knowledge in C, I just know the printf() function. *So if anyone can give a hint on the Concept by managing the GTP linux module using netlink, just the Concept, not how to do it by code, would be really appreciated.* Best Regards, Le ven. 21 ao?t 2020 ? 16:57, Papa Tana a ?crit : > > At least earlier versions of ergw had support for the kernel GTP-U > plane, why > not simply use that code? > My experience with erlang is very limited so far, that's why I was > attracted with libgtpnl, because I was able to create a GTP tunnel by > invoking only 2 lines > # ./gtp-link add > # ./gtp-tunnel add > > > They created https://github.com/travelping/gen_netlink to talk netlink > from > erlang, including gtpnl support. > Yes, I saw it. but even trying to build it from tetrapak, I have made some > search but I'm struggling: > # tetrapak build check (don't even know what is tetrapak :-) ) > > The creators of these libraries already answer some questions from me in > the public erlang mailing list, but about general erlang related questions. > I didn't find any public mailing list to these libraries, so I gave up. > > > You cannot do that, sorry. > > This will obviously not work. > > You need to manage the socket from your program. > > You are asking for the impossible. > > I totally agree with you but I've got some idea this afternoon as a > workaround. > I think I can forward the echo-request that I received on my network > interface (owned by gtpnl at GTP-U) to my Erlang program by using some > Linux helper like > # tcpdump > # replay the traffic by tcpreplay to another interface owned by my Erlang > program > # or I can Write them to a Linux named pipe fifo, and get it from Erlang > > By this way, I would be able to craft an echo-response for GTP-U I think. > > Those steps are not related to libgtpnl anymore, so would be off-topic. > > But Clarifications regarding libgtpnl is very clear for me now. > > Thank you, > > P.S: I will update here if this echo-response at GTP-U side from my erlang > works for me. Have a nice day. > > Le ven. 21 ao?t 2020 ? 15:40, Harald Welte a > ?crit : > >> On Fri, Aug 21, 2020 at 09:53:34AM +0300, Papa Tana wrote: >> > But for GTP-U, I was trying to listen in port 2152 several times, and it >> > yields an error that I cannot listen on it, port 2152 is already used. >> >> You cannot do that, sorry. >> >> > > You manage all your UDP sockets. >> > > your application is responsible for receiving and responding to any >> GTP-U >> > packets there. >> > As I said, I am using Erlang as a userspace program. >> > And when I create a tunnel, I "just" send a basic command exec to the >> Linux >> > by open_port like this: >> >> This will obviously not work. You need to manage the socket from your >> program. >> >> IF it's erlang, you either have to speak netlink directly from within >> Erlang, >> or you need to add some native functions for calling libgtpnl. >> >> > So I don't have any idea on how to listen to 2152 as my Erlang program >> is >> > forbidden to listen on it when libgtpnl is invoked. >> >> You are asking for the impossible. You need to open the socket from >> within your >> program. You cannot crate a second socket for what you are trying to do. >> >> At least earlier versions of ergw had support for the kernel GTP-U plane, >> why not simply use that code? >> >> They created https://github.com/travelping/gen_netlink >> to talk netlink from erlang, including gtpnl support. >> >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From papa.tana101 at gmail.com Sun Aug 23 21:06:54 2020 From: papa.tana101 at gmail.com (Papa Tana) Date: Mon, 24 Aug 2020 00:06:54 +0300 Subject: GTP tunnel seems to exist, but No encapsulation when using libgtpnl In-Reply-To: References: <20200810195854.GK2338189@nataraja> <20200820225145.GL3544863@nataraja> <20200821123438.GO3544863@nataraja> Message-ID: Hi, An update as promised, I tried my workaround: - sniff from userspace the echo-request sent by peer SGSN to libgtpnl: OK - craft a message (echo-response) and send it to SGSN: OK from another port, but NOK from 2152 Whatever I tried (bind to low level socket, Linux helper, etc...), it was impossible because the SGSN only accepts the message that he recognize that he has sent, and wait for the exact pair {ip, port} so, it was impossible for me since it was owned by libgtpnl when I invoke "gtp-link add". The previous suggestion is really interesting to me: * - speak netlink directly to the GTP-U module.* Yes, there is some library that can speak netlink, but since I want to learn first how to do it without using a library, I have learned how to speak netlink to Linux Module (libnl-genl). I have checked out the message structure(headers, length, type, flags, sequence number, pid, Command, Data, ....). I have monitored some stuff by using "nlmon". And now, I can create a netlink socket as a File Descriptor, craft some Netlink Message manually, flush it to the kernel and receive some response from a sample kernel module. But my question is, and what I need help with, what data does GTP.ko expect from me when I need to request an add or delete tunnel, since I cannot see any documentation about Linux GTP module interface. I'm not requesting a code, but only the message or binary I need to transport in my netlink socket towards GTP-U Linux module. Thanks for any help or hint, Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From davem at davemloft.net Tue Aug 25 13:29:31 2020 From: davem at davemloft.net (David Miller) Date: Tue, 25 Aug 2020 06:29:31 -0700 (PDT) Subject: [PATCH net] gtp: add GTPA_LINK info to msg sent to userspace In-Reply-To: <20200825125940.21238-1-nicolas.dichtel@6wind.com> References: <20200825125940.21238-1-nicolas.dichtel@6wind.com> Message-ID: <20200825.062931.1607380647178219957.davem@davemloft.net> From: Nicolas Dichtel Date: Tue, 25 Aug 2020 14:59:40 +0200 > During a dump, this attribute is essential, it enables the userspace to > know on which interface the context is linked to. > > Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") > Signed-off-by: Nicolas Dichtel > Tested-by: Gabriel Ganne Applied and queued up for -stable, thank you. From laforge at gnumonks.org Tue Aug 25 17:01:09 2020 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 25 Aug 2020 19:01:09 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <20200825155715.24006-1-nicolas.dichtel@6wind.com> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> Message-ID: <20200825170109.GH3822842@nataraja> Hi Nicolas, thanks a lot for your patch. On Tue, Aug 25, 2020 at 05:57:15PM +0200, Nicolas Dichtel wrote: > Like all other network functions, let's notify gtp context on creation and > deletion. While this may be in-line with typical kernel tunnel device practises, I am not convinced it is the right way to go for GTP. Contrary to other tunneling mechansims, GTP doesn't have a 1:1 rlationship between tunnels and netdev's. You can easily have tens of thousands - or even many more - PDP contexts (at least one per subscriber) within one "gtp0" netdev. Also, the state is highly volatile. Every time a subscriber registers/deregisters, goes in or out of coverage, in or out of airplane mode, etc. those PDP contexts go up and down. Sending (unsolicited) notifications about all of those seems quite heavyweight to me. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nicolas.dichtel at 6wind.com Tue Aug 25 12:59:40 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Tue, 25 Aug 2020 14:59:40 +0200 Subject: [PATCH net] gtp: add GTPA_LINK info to msg sent to userspace Message-ID: <20200825125940.21238-1-nicolas.dichtel@6wind.com> During a dump, this attribute is essential, it enables the userspace to know on which interface the context is linked to. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Nicolas Dichtel Tested-by: Gabriel Ganne --- I target this to net, because I think this is a bug fix. The dump result cannot be used if there is more than one gtp interface on the system. drivers/net/gtp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 21640a035d7d..8e47d0112e5d 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1179,6 +1179,7 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, goto nlmsg_failure; if (nla_put_u32(skb, GTPA_VERSION, pctx->gtp_version) || + nla_put_u32(skb, GTPA_LINK, pctx->dev->ifindex) || nla_put_be32(skb, GTPA_PEER_ADDRESS, pctx->peer_addr_ip4.s_addr) || nla_put_be32(skb, GTPA_MS_ADDRESS, pctx->ms_addr_ip4.s_addr)) goto nla_put_failure; -- 2.26.2 From nicolas.dichtel at 6wind.com Tue Aug 25 14:35:56 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Tue, 25 Aug 2020 16:35:56 +0200 Subject: [PATCH net-next] gtp: add notification mechnism Message-ID: <20200825143556.23766-1-nicolas.dichtel@6wind.com> Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by: Nicolas Dichtel Tested-by: Gabriel Ganne --- drivers/net/gtp.c | 58 +++++++++++++++++++++++++++++++++------- include/uapi/linux/gtp.h | 2 ++ 2 files changed, 51 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 8e47d0112e5d..360c1dc9381e 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -928,8 +928,8 @@ static void ipv4_pdp_fill(struct pdp_ctx *pctx, struct genl_info *info) } } -static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, - struct genl_info *info) +static struct pdp_ctx *gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, + struct genl_info *info) { struct pdp_ctx *pctx, *pctx_tid = NULL; struct net_device *dev = gtp->dev; @@ -956,12 +956,12 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, if (found) { if (info->nlhdr->nlmsg_flags & NLM_F_EXCL) - return -EEXIST; + return ERR_PTR(-EEXIST); if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE) - return -EOPNOTSUPP; + return ERR_PTR(-EOPNOTSUPP); if (pctx && pctx_tid) - return -EEXIST; + return ERR_PTR(-EEXIST); if (!pctx) pctx = pctx_tid; @@ -974,13 +974,13 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, netdev_dbg(dev, "GTPv1-U: update tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); - return 0; + return pctx; } pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) - return -ENOMEM; + return ERR_PTR(-ENOMEM); sock_hold(sk); pctx->sk = sk; @@ -1018,7 +1018,7 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, break; } - return 0; + return pctx; } static void pdp_context_free(struct rcu_head *head) @@ -1036,9 +1036,12 @@ static void pdp_context_delete(struct pdp_ctx *pctx) call_rcu(&pctx->rcu_head, pdp_context_free); } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd); + static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) { unsigned int version; + struct pdp_ctx *pctx; struct gtp_dev *gtp; struct sock *sk; int err; @@ -1088,7 +1091,13 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } - err = gtp_pdp_add(gtp, sk, info); + pctx = gtp_pdp_add(gtp, sk, info); + if (IS_ERR(pctx)) { + err = PTR_ERR(pctx); + } else { + gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP); + err = 0; + } out_unlock: rcu_read_unlock(); @@ -1159,6 +1168,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) netdev_dbg(pctx->dev, "GTPv1-U: deleting tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); + gtp_tunnel_notify(pctx, GTP_CMD_DELPDP); pdp_context_delete(pctx); out_unlock: @@ -1168,6 +1178,14 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) static struct genl_family gtp_genl_family; +enum gtp_multicast_groups { + GTP_GENL_MCGRP, +}; + +static const struct genl_multicast_group gtp_genl_mcgrps[] = { + [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME }, +}; + static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, int flags, u32 type, struct pdp_ctx *pctx) { @@ -1205,6 +1223,26 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, return -EMSGSIZE; } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd) +{ + struct sk_buff *msg; + int ret; + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + + ret = gtp_genl_fill_info(msg, 0, 0, 0, cmd, pctx); + if (ret < 0) { + nlmsg_free(msg); + return ret; + } + + ret = genlmsg_multicast_netns(>p_genl_family, dev_net(pctx->dev), msg, + 0, GTP_GENL_MCGRP, GFP_ATOMIC); + return ret; +} + static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; @@ -1335,6 +1373,8 @@ static struct genl_family gtp_genl_family __ro_after_init = { .module = THIS_MODULE, .ops = gtp_genl_ops, .n_ops = ARRAY_SIZE(gtp_genl_ops), + .mcgrps = gtp_genl_mcgrps, + .n_mcgrps = ARRAY_SIZE(gtp_genl_mcgrps), }; static int __net_init gtp_net_init(struct net *net) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index c7d66755d212..79f9191bbb24 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -2,6 +2,8 @@ #ifndef _UAPI_LINUX_GTP_H_ #define _UAPI_LINUX_GTP_H_ +#define GTP_GENL_MCGRP_NAME "gtp" + enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, -- 2.26.2 From nicolas.dichtel at 6wind.com Tue Aug 25 15:57:15 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Tue, 25 Aug 2020 17:57:15 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <20200825143556.23766-1-nicolas.dichtel@6wind.com> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> Message-ID: <20200825155715.24006-1-nicolas.dichtel@6wind.com> Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by: Nicolas Dichtel Tested-by: Gabriel Ganne --- v1 -> v2: - fix typo in the commit title - fix indentation of GTP_GENL_MCGRP drivers/net/gtp.c | 58 +++++++++++++++++++++++++++++++++------- include/uapi/linux/gtp.h | 2 ++ 2 files changed, 51 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 8e47d0112e5d..76fd87a44fdf 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -928,8 +928,8 @@ static void ipv4_pdp_fill(struct pdp_ctx *pctx, struct genl_info *info) } } -static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, - struct genl_info *info) +static struct pdp_ctx *gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, + struct genl_info *info) { struct pdp_ctx *pctx, *pctx_tid = NULL; struct net_device *dev = gtp->dev; @@ -956,12 +956,12 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, if (found) { if (info->nlhdr->nlmsg_flags & NLM_F_EXCL) - return -EEXIST; + return ERR_PTR(-EEXIST); if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE) - return -EOPNOTSUPP; + return ERR_PTR(-EOPNOTSUPP); if (pctx && pctx_tid) - return -EEXIST; + return ERR_PTR(-EEXIST); if (!pctx) pctx = pctx_tid; @@ -974,13 +974,13 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, netdev_dbg(dev, "GTPv1-U: update tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); - return 0; + return pctx; } pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) - return -ENOMEM; + return ERR_PTR(-ENOMEM); sock_hold(sk); pctx->sk = sk; @@ -1018,7 +1018,7 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, break; } - return 0; + return pctx; } static void pdp_context_free(struct rcu_head *head) @@ -1036,9 +1036,12 @@ static void pdp_context_delete(struct pdp_ctx *pctx) call_rcu(&pctx->rcu_head, pdp_context_free); } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd); + static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) { unsigned int version; + struct pdp_ctx *pctx; struct gtp_dev *gtp; struct sock *sk; int err; @@ -1088,7 +1091,13 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } - err = gtp_pdp_add(gtp, sk, info); + pctx = gtp_pdp_add(gtp, sk, info); + if (IS_ERR(pctx)) { + err = PTR_ERR(pctx); + } else { + gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP); + err = 0; + } out_unlock: rcu_read_unlock(); @@ -1159,6 +1168,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) netdev_dbg(pctx->dev, "GTPv1-U: deleting tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); + gtp_tunnel_notify(pctx, GTP_CMD_DELPDP); pdp_context_delete(pctx); out_unlock: @@ -1168,6 +1178,14 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) static struct genl_family gtp_genl_family; +enum gtp_multicast_groups { + GTP_GENL_MCGRP, +}; + +static const struct genl_multicast_group gtp_genl_mcgrps[] = { + [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME }, +}; + static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, int flags, u32 type, struct pdp_ctx *pctx) { @@ -1205,6 +1223,26 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, return -EMSGSIZE; } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd) +{ + struct sk_buff *msg; + int ret; + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + + ret = gtp_genl_fill_info(msg, 0, 0, 0, cmd, pctx); + if (ret < 0) { + nlmsg_free(msg); + return ret; + } + + ret = genlmsg_multicast_netns(>p_genl_family, dev_net(pctx->dev), msg, + 0, GTP_GENL_MCGRP, GFP_ATOMIC); + return ret; +} + static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; @@ -1335,6 +1373,8 @@ static struct genl_family gtp_genl_family __ro_after_init = { .module = THIS_MODULE, .ops = gtp_genl_ops, .n_ops = ARRAY_SIZE(gtp_genl_ops), + .mcgrps = gtp_genl_mcgrps, + .n_mcgrps = ARRAY_SIZE(gtp_genl_mcgrps), }; static int __net_init gtp_net_init(struct net *net) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index c7d66755d212..79f9191bbb24 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -2,6 +2,8 @@ #ifndef _UAPI_LINUX_GTP_H_ #define _UAPI_LINUX_GTP_H_ +#define GTP_GENL_MCGRP_NAME "gtp" + enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, -- 2.26.2 From nicolas.dichtel at 6wind.com Wed Aug 26 07:47:54 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Wed, 26 Aug 2020 09:47:54 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <20200825170109.GH3822842@nataraja> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> <20200825170109.GH3822842@nataraja> Message-ID: Le 25/08/2020 ? 19:01, Harald Welte a ?crit?: > Hi Nicolas, > > thanks a lot for your patch. > > On Tue, Aug 25, 2020 at 05:57:15PM +0200, Nicolas Dichtel wrote: >> Like all other network functions, let's notify gtp context on creation and >> deletion. > > While this may be in-line with typical kernel tunnel device practises, I am not > convinced it is the right way to go for GTP. > > Contrary to other tunneling mechansims, GTP doesn't have a 1:1 rlationship between > tunnels and netdev's. You can easily have tens of thousands - or even many more - > PDP contexts (at least one per subscriber) within one "gtp0" netdev. Also, the state > is highly volatile. Every time a subscriber registers/deregisters, goes in or out of > coverage, in or out of airplane mode, etc. those PDP contexts go up and down. > > Sending (unsolicited) notifications about all of those seems quite heavyweight to me. There is no 'unsolicited' notifications with this patch. Notifications are sent only if a userspace application has subscribed to the gtp mcast group. ip routes or conntrack entries are notified in the same way and there could a lot of them also (more than 100k conntrack entries for example). From laforge at gnumonks.org Wed Aug 26 18:52:02 2020 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 26 Aug 2020 20:52:02 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> <20200825170109.GH3822842@nataraja> Message-ID: <20200826185202.GZ3739@nataraja> Hi Nicolas, On Wed, Aug 26, 2020 at 09:47:54AM +0200, Nicolas Dichtel wrote: > > Sending (unsolicited) notifications about all of those seems quite heavyweight to me. > > There is no 'unsolicited' notifications with this patch. Notifications are sent > only if a userspace application has subscribed to the gtp mcast group. > ip routes or conntrack entries are notified in the same way and there could a > lot of them also (more than 100k conntrack entries for example). Ok, thanks for reminding me of that. However, even if those events are not sent/multicasted, it still looks like the proposed patch is unconditionally allocating a netlink message and filling it with information about the PDP. That alone looks like adding significant overhead to every user - even the majority of current use cases where nobody is listening/subscribing to that multicast group. Wouldn't it make sense to only allocate + fill those messages if we actually knew a subscriber existed? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nicolas.dichtel at 6wind.com Wed Aug 26 22:36:24 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Thu, 27 Aug 2020 00:36:24 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <20200826185202.GZ3739@nataraja> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> <20200825170109.GH3822842@nataraja> <20200826185202.GZ3739@nataraja> Message-ID: <0e2c4c04-a6dc-d081-2bdd-09f8d78607c4@6wind.com> Le 26/08/2020 ? 20:52, Harald Welte a ?crit?: > Hi Nicolas, > > On Wed, Aug 26, 2020 at 09:47:54AM +0200, Nicolas Dichtel wrote: >>> Sending (unsolicited) notifications about all of those seems quite heavyweight to me. >> >> There is no 'unsolicited' notifications with this patch. Notifications are sent >> only if a userspace application has subscribed to the gtp mcast group. >> ip routes or conntrack entries are notified in the same way and there could a >> lot of them also (more than 100k conntrack entries for example). > > Ok, thanks for reminding me of that. However, even if those events are > not sent/multicasted, it still looks like the proposed patch is > unconditionally allocating a netlink message and filling it with > information about the PDP. That alone looks like adding significant > overhead to every user - even the majority of current use cases where > nobody is listening/subscribing to that multicast group. I don't think that this is a significant overhead. This is added in the control path. When a PDP context is added, the rtnl lock is took, this is another magnitude of overhead than a kmalloc(). > > Wouldn't it make sense to only allocate + fill those messages if we > actually knew a subscriber existed? In fact, this is actually how the netlink framework works. From laforge at gnumonks.org Thu Aug 27 09:00:26 2020 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 27 Aug 2020 11:00:26 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <0e2c4c04-a6dc-d081-2bdd-09f8d78607c4@6wind.com> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> <20200825170109.GH3822842@nataraja> <20200826185202.GZ3739@nataraja> <0e2c4c04-a6dc-d081-2bdd-09f8d78607c4@6wind.com> Message-ID: <20200827090026.GK130874@nataraja> Hi Nicolas, On Thu, Aug 27, 2020 at 12:36:24AM +0200, Nicolas Dichtel wrote: > Le 26/08/2020 ? 20:52, Harald Welte a ?crit?: > > Wouldn't it make sense to only allocate + fill those messages if we > > actually knew a subscriber existed? > > In fact, this is actually how the netlink framework works. Well, as you can tell from my responses, I've not been doing kernel work for a decade now, so I'm looking at things from a more distant and ignorant perspective. To me it seems odd to allocate memory and copy data to it (cache misses, ...) if nobody every requested that data, and nobody will ever use it. But if this is how it is supposed to work, then I will of course defer to that. All netlink would have to expose is a function that returns whether or not there are any subscribers to the given multicast group. Then all of the allocation + initialization would disappear in a branch that is not executed most of the time, at least for current, existing gtpnl systems. Yes, that means one more branch, of course. But that branch will happen later on anyway, event today: Only after the allocation + initialization. So having said the above, if this is how it is supposed to work with netlink: Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nicolas.dichtel at 6wind.com Thu Aug 27 10:25:47 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Thu, 27 Aug 2020 12:25:47 +0200 Subject: [PATCH net-next v2] gtp: add notification mechanism In-Reply-To: <20200827090026.GK130874@nataraja> References: <20200825143556.23766-1-nicolas.dichtel@6wind.com> <20200825155715.24006-1-nicolas.dichtel@6wind.com> <20200825170109.GH3822842@nataraja> <20200826185202.GZ3739@nataraja> <0e2c4c04-a6dc-d081-2bdd-09f8d78607c4@6wind.com> <20200827090026.GK130874@nataraja> Message-ID: <784761a0-a01d-a05b-e624-40c13f9a5771@6wind.com> Hi Harald, Le 27/08/2020 ? 11:00, Harald Welte a ?crit?: > Hi Nicolas, > > On Thu, Aug 27, 2020 at 12:36:24AM +0200, Nicolas Dichtel wrote: >> Le 26/08/2020 ? 20:52, Harald Welte a ?crit?: > >>> Wouldn't it make sense to only allocate + fill those messages if we >>> actually knew a subscriber existed? >> >> In fact, this is actually how the netlink framework works. > > Well, as you can tell from my responses, I've not been doing kernel work > for a decade now, so I'm looking at things from a more distant and > ignorant perspective. To me it seems odd to allocate memory and copy > data to it (cache misses, ...) if nobody every requested that data, and > nobody will ever use it. But if this is how it is supposed to work, > then I will of course defer to that. All netlink would have to expose > is a function that returns whether or not there are any subscribers > to the given multicast group. Then all of the allocation + > initialization would disappear in a branch that is not executed most of > the time, at least for current, existing gtpnl systems. Yes, that means > one more branch, of course. But that branch will happen later on > anyway, event today: Only after the allocation + initialization. I agree, but I didn't find a good solution for this right now. The lookup is not straight forward. > > So having said the above, if this is how it is supposed to work with > netlink: > > Acked-by: Harald Welte > Thank you. From nicolas.dichtel at 6wind.com Thu Aug 27 12:19:23 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Thu, 27 Aug 2020 14:19:23 +0200 Subject: [PATCH net-next v3] gtp: add notification mechanism In-Reply-To: <20200827090026.GK130874@nataraja> References: <20200827090026.GK130874@nataraja> Message-ID: <20200827121923.7302-1-nicolas.dichtel@6wind.com> Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by: Nicolas Dichtel Tested-by: Gabriel Ganne Acked-by: Harald Welte --- v2 -> v3: - add ack from Harald - rebase on HEAD of net-next v1 -> v2: - fix typo in the commit title - fix indentation of GTP_GENL_MCGRP drivers/net/gtp.c | 58 +++++++++++++++++++++++++++++++++------- include/uapi/linux/gtp.h | 2 ++ 2 files changed, 51 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 21640a035d7d..c84a10569388 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -928,8 +928,8 @@ static void ipv4_pdp_fill(struct pdp_ctx *pctx, struct genl_info *info) } } -static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, - struct genl_info *info) +static struct pdp_ctx *gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, + struct genl_info *info) { struct pdp_ctx *pctx, *pctx_tid = NULL; struct net_device *dev = gtp->dev; @@ -956,12 +956,12 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, if (found) { if (info->nlhdr->nlmsg_flags & NLM_F_EXCL) - return -EEXIST; + return ERR_PTR(-EEXIST); if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE) - return -EOPNOTSUPP; + return ERR_PTR(-EOPNOTSUPP); if (pctx && pctx_tid) - return -EEXIST; + return ERR_PTR(-EEXIST); if (!pctx) pctx = pctx_tid; @@ -974,13 +974,13 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, netdev_dbg(dev, "GTPv1-U: update tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); - return 0; + return pctx; } pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) - return -ENOMEM; + return ERR_PTR(-ENOMEM); sock_hold(sk); pctx->sk = sk; @@ -1018,7 +1018,7 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, break; } - return 0; + return pctx; } static void pdp_context_free(struct rcu_head *head) @@ -1036,9 +1036,12 @@ static void pdp_context_delete(struct pdp_ctx *pctx) call_rcu(&pctx->rcu_head, pdp_context_free); } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd); + static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) { unsigned int version; + struct pdp_ctx *pctx; struct gtp_dev *gtp; struct sock *sk; int err; @@ -1088,7 +1091,13 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } - err = gtp_pdp_add(gtp, sk, info); + pctx = gtp_pdp_add(gtp, sk, info); + if (IS_ERR(pctx)) { + err = PTR_ERR(pctx); + } else { + gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP); + err = 0; + } out_unlock: rcu_read_unlock(); @@ -1159,6 +1168,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) netdev_dbg(pctx->dev, "GTPv1-U: deleting tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); + gtp_tunnel_notify(pctx, GTP_CMD_DELPDP); pdp_context_delete(pctx); out_unlock: @@ -1168,6 +1178,14 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) static struct genl_family gtp_genl_family; +enum gtp_multicast_groups { + GTP_GENL_MCGRP, +}; + +static const struct genl_multicast_group gtp_genl_mcgrps[] = { + [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME }, +}; + static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, int flags, u32 type, struct pdp_ctx *pctx) { @@ -1204,6 +1222,26 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, return -EMSGSIZE; } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd) +{ + struct sk_buff *msg; + int ret; + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + + ret = gtp_genl_fill_info(msg, 0, 0, 0, cmd, pctx); + if (ret < 0) { + nlmsg_free(msg); + return ret; + } + + ret = genlmsg_multicast_netns(>p_genl_family, dev_net(pctx->dev), msg, + 0, GTP_GENL_MCGRP, GFP_ATOMIC); + return ret; +} + static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; @@ -1334,6 +1372,8 @@ static struct genl_family gtp_genl_family __ro_after_init = { .module = THIS_MODULE, .ops = gtp_genl_ops, .n_ops = ARRAY_SIZE(gtp_genl_ops), + .mcgrps = gtp_genl_mcgrps, + .n_mcgrps = ARRAY_SIZE(gtp_genl_mcgrps), }; static int __net_init gtp_net_init(struct net *net) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index c7d66755d212..79f9191bbb24 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -2,6 +2,8 @@ #ifndef _UAPI_LINUX_GTP_H_ #define _UAPI_LINUX_GTP_H_ +#define GTP_GENL_MCGRP_NAME "gtp" + enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, -- 2.26.2 From davem at davemloft.net Thu Aug 27 15:05:14 2020 From: davem at davemloft.net (David Miller) Date: Thu, 27 Aug 2020 08:05:14 -0700 (PDT) Subject: [PATCH net-next v3] gtp: add notification mechanism In-Reply-To: <20200827121923.7302-1-nicolas.dichtel@6wind.com> References: <20200827090026.GK130874@nataraja> <20200827121923.7302-1-nicolas.dichtel@6wind.com> Message-ID: <20200827.080514.1573033574724120328.davem@davemloft.net> From: Nicolas Dichtel Date: Thu, 27 Aug 2020 14:19:23 +0200 > Like all other network functions, let's notify gtp context on creation and > deletion. > > Signed-off-by: Nicolas Dichtel > Tested-by: Gabriel Ganne > Acked-by: Harald Welte Applied, thanks. From nicolas.dichtel at 6wind.com Thu Aug 27 16:37:32 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Thu, 27 Aug 2020 18:37:32 +0200 Subject: [PATCH net-next v3] gtp: add notification mechanism In-Reply-To: <20200827.080514.1573033574724120328.davem@davemloft.net> References: <20200827090026.GK130874@nataraja> <20200827121923.7302-1-nicolas.dichtel@6wind.com> <20200827.080514.1573033574724120328.davem@davemloft.net> Message-ID: Le 27/08/2020 ? 17:05, David Miller a ?crit?: > From: Nicolas Dichtel > Date: Thu, 27 Aug 2020 14:19:23 +0200 > >> Like all other network functions, let's notify gtp context on creation and >> deletion. >> >> Signed-off-by: Nicolas Dichtel >> Tested-by: Gabriel Ganne >> Acked-by: Harald Welte > > Applied, thanks. > I don't see the changes here: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/log/ Some build tests? Or just a missing push? ;-) Thank you, Nicolas From davem at davemloft.net Thu Aug 27 16:44:12 2020 From: davem at davemloft.net (David Miller) Date: Thu, 27 Aug 2020 09:44:12 -0700 (PDT) Subject: [PATCH net-next v3] gtp: add notification mechanism In-Reply-To: References: <20200827121923.7302-1-nicolas.dichtel@6wind.com> <20200827.080514.1573033574724120328.davem@davemloft.net> Message-ID: <20200827.094412.1386296048660013556.davem@davemloft.net> From: Nicolas Dichtel Date: Thu, 27 Aug 2020 18:37:32 +0200 > Le 27/08/2020 ? 17:05, David Miller a ?crit?: >> From: Nicolas Dichtel >> Date: Thu, 27 Aug 2020 14:19:23 +0200 >> >>> Like all other network functions, let's notify gtp context on creation and >>> deletion. >>> >>> Signed-off-by: Nicolas Dichtel >>> Tested-by: Gabriel Ganne >>> Acked-by: Harald Welte >> >> Applied, thanks. >> > I don't see the changes here: > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/log/ > > Some build tests? Or just a missing push? ;-) Was build testing, it's pushed out now. From nicolas.dichtel at 6wind.com Thu Aug 27 16:45:31 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Thu, 27 Aug 2020 18:45:31 +0200 Subject: [PATCH net-next v3] gtp: add notification mechanism In-Reply-To: <20200827.094412.1386296048660013556.davem@davemloft.net> References: <20200827121923.7302-1-nicolas.dichtel@6wind.com> <20200827.080514.1573033574724120328.davem@davemloft.net> <20200827.094412.1386296048660013556.davem@davemloft.net> Message-ID: <0c472a87-00b3-55d9-c1d8-9ba09a1fd0bc@6wind.com> Le 27/08/2020 ? 18:44, David Miller a ?crit?: > Was build testing, it's pushed out now. > Thanks David! From nicolas.dichtel at 6wind.com Fri Aug 28 13:30:55 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Fri, 28 Aug 2020 15:30:55 +0200 Subject: [PATCH net-next 1/2] gtp: remove useless rcu_read_lock() In-Reply-To: <20200828133056.22751-1-nicolas.dichtel@6wind.com> References: <20200828133056.22751-1-nicolas.dichtel@6wind.com> Message-ID: <20200828133056.22751-2-nicolas.dichtel@6wind.com> The rtnl lock is taken just the line above, no need to take the rcu also. Fixes: 1788b8569f5d ("gtp: fix use-after-free in gtp_encap_destroy()") Signed-off-by: Nicolas Dichtel --- drivers/net/gtp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index c84a10569388..6f871ec31393 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1071,7 +1071,6 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) } rtnl_lock(); - rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); if (!gtp) { @@ -1100,7 +1099,6 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) } out_unlock: - rcu_read_unlock(); rtnl_unlock(); return err; } -- 2.26.2 From nicolas.dichtel at 6wind.com Fri Aug 28 13:30:56 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Fri, 28 Aug 2020 15:30:56 +0200 Subject: [PATCH net-next 2/2] gtp: relax alloc constraint when adding a pdp In-Reply-To: <20200828133056.22751-1-nicolas.dichtel@6wind.com> References: <20200828133056.22751-1-nicolas.dichtel@6wind.com> Message-ID: <20200828133056.22751-3-nicolas.dichtel@6wind.com> When a PDP context is added, the rtnl lock is held, thus no need to force a GFP_ATOMIC. Signed-off-by: Nicolas Dichtel --- drivers/net/gtp.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 6f871ec31393..2ed1e82a8ad8 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1036,7 +1036,7 @@ static void pdp_context_delete(struct pdp_ctx *pctx) call_rcu(&pctx->rcu_head, pdp_context_free); } -static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd); +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd, gfp_t allocation); static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) { @@ -1094,7 +1094,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) if (IS_ERR(pctx)) { err = PTR_ERR(pctx); } else { - gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP); + gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP, GFP_KERNEL); err = 0; } @@ -1166,7 +1166,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) netdev_dbg(pctx->dev, "GTPv1-U: deleting tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); - gtp_tunnel_notify(pctx, GTP_CMD_DELPDP); + gtp_tunnel_notify(pctx, GTP_CMD_DELPDP, GFP_ATOMIC); pdp_context_delete(pctx); out_unlock: @@ -1220,12 +1220,12 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, return -EMSGSIZE; } -static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd) +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd, gfp_t allocation) { struct sk_buff *msg; int ret; - msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, allocation); if (!msg) return -ENOMEM; -- 2.26.2 From nicolas.dichtel at 6wind.com Fri Aug 28 13:30:54 2020 From: nicolas.dichtel at 6wind.com (Nicolas Dichtel) Date: Fri, 28 Aug 2020 15:30:54 +0200 Subject: [PATCH net-next 0/2] gtp: minor enhancements Message-ID: <20200828133056.22751-1-nicolas.dichtel@6wind.com> The first patch removes a useless rcu lock and the second relax alloc constraints when a PDP context is added. drivers/net/gtp.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) Comments are welcomed, Nicolas From davem at davemloft.net Mon Aug 31 19:24:48 2020 From: davem at davemloft.net (David Miller) Date: Mon, 31 Aug 2020 12:24:48 -0700 (PDT) Subject: [PATCH net-next 0/2] gtp: minor enhancements In-Reply-To: <20200828133056.22751-1-nicolas.dichtel@6wind.com> References: <20200828133056.22751-1-nicolas.dichtel@6wind.com> Message-ID: <20200831.122448.218384742586415389.davem@davemloft.net> From: Nicolas Dichtel Date: Fri, 28 Aug 2020 15:30:54 +0200 > The first patch removes a useless rcu lock and the second relax alloc > constraints when a PDP context is added. Series applied, thanks.