Hi, On Thu, Mar 21, 2019 at 9:10 PM David Miller <da...@davemloft.net> wrote: > This seems to allow adding both a wildcarded and a non-wildcarded fou > socket, which otherwise has overlapping match scenerios. > > I don't think you want to allow that unless you can determine that > you aren't creating a situation where multiple fou sockets could > match the same tunneled packet.
(Apologies to David for multiple copies of this reply. I thought I was safe from HTML-encoded emails when using Gmail through the browser. Turns out not to be true for mobile ...) Thanks for your comments and apoligies for my late reply, Gmail flagged you message as spam for some reason. I tried to test and make sure that we would not get any false positives when mixing non-wildcarded/wildcarded sockets. In my tests, I first created a wildcard socket bound to port 9999. I then tried to add a second, non-wildcarded socket bound to the same port. I also tried to fetch and delete the socket, including souce address, peer address or interface index in the netlink request. Both the create, fetch and delete request failed. Deleting/fetching the socket was only successful when my netlink request attributes matched those used to create the socket. I then did the same tests, but with a socket bound to a local ip address, a socket bound to a local address + interface, and a bound socket that was also «connected» to a peer. Add only worked when no socket with the matching source address/interface (or wildcard) existed, while fetch/delete was only succesful when all attributes matched. Perhaps there is something I am misunderstanding, or a case I am not aware of? Thanks again for your comments! BR, Kristian
