On Tue, Apr 7, 2015, at 06:45, Tom Herbert wrote: > On Mon, Apr 6, 2015 at 8:51 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: > > I don't see what is convoluted about using the correct socket for > > sending L3 protocol frames. That's in fact how it's _supposed_ to > > work. And consistently having a proper matching socket available > > makes it so that, long-term, we'll never have to deal with this issue > > ever again. > > I guess this is where I'm confused. We can send just about anything > over GRE also, but have never needed a transmit socket for that. Is > UDP encapsulation so different, or is GRE equally broken also? Also, > will we need to add the socket to FOU and GUE then? GRE, FOU, GUE in case of sk_mc_loop and the destination is a multicast address, we imply sk_mc_loop() == true, what is not what we want. Tunnel sockets deliberately set mc_loop to false but we cannot adhere to them, yet. David's patchset changes that. Also, I saw one inconsistency with sk_bound_dev_if in netfilter which doesn't get solved by this patchset (it uses skb->sk->sk_bound_dev_if unconditionally). I think that having a struct-sock carrying over meta-information is a good thing. Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
