On Mon, Apr 6, 2015 at 8:51 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Tom Herbert <tom@xxxxxxxxxxxxxxx> > Date: Mon, 6 Apr 2015 19:43:11 -0700 > >> To be honest, requiring an additional socket to transmit UDP >> encapsulation seems really convoluted to me, especially considering >> that this is just trying trying to solve AF_PACKET in nf which seems >> like a narrow use case. Is there no way to test for AF_PACKET sockets >> and take action at a lower function? Does every type encapsulation >> need its own UDP socket, or can you just have one which set from the >> udp_tunnel when family of skb->sk is AF_PACKET? > > This has nothing to do with netfilter. > > This has everything to do with being able to pass a socket down > through the complete ipv4/ipv6 output path. That's the only > reason netfilter needed to be touched. > > The ipv4/ipv6 output call paths have the NF hooks in the middle, and > the NF hooks determine what the call signature is for the rest of the > output path. That's why it needed to be adjusted. > > For ipv6 fragmentation, in particular, having the right ipv4/ipv6 > socket is going to be important. > > AF_PACKET is not an isolated case, just the most likely example. It's > just as easy to trigger this problem for other protocol families too. > You can send appletalk packets over VXLAN. > > 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? Thanks, Tom -- 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
