Re: [PATCH] net: VRF: Fix receiving multicast traffic

2016-09-23 Thread David Ahern
On 9/22/16 9:06 PM, Mark Tomlinson wrote: > > On 09/23/2016 10:41 AM, David Ahern wrote: >> On 9/22/16 4:10 PM, Mark Tomlinson wrote: >>> On 09/23/2016 03:14 AM, David Ahern wrote: l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working a

Re: [PATCH] net: VRF: Fix receiving multicast traffic

2016-09-22 Thread Mark Tomlinson
On 09/23/2016 10:41 AM, David Ahern wrote: > On 9/22/16 4:10 PM, Mark Tomlinson wrote: >> On 09/23/2016 03:14 AM, David Ahern wrote: >>> l3mdev devices do not support IPv4 multicast so checking mcast against that >>> device should not be working at all. For that reason I was fine with the >>> ch

Re: [PATCH] net: VRF: Fix receiving multicast traffic

2016-09-22 Thread David Ahern
On 9/22/16 4:10 PM, Mark Tomlinson wrote: > > On 09/23/2016 03:14 AM, David Ahern wrote: >> >> l3mdev devices do not support IPv4 multicast so checking mcast against that >> device should not be working at all. For that reason I was fine with the >> change in the previous patch. ie., you want th

Re: [PATCH] net: VRF: Fix receiving multicast traffic

2016-09-22 Thread Mark Tomlinson
On 09/23/2016 03:14 AM, David Ahern wrote: > > l3mdev devices do not support IPv4 multicast so checking mcast against that > device should not be working at all. For that reason I was fine with the > change in the previous patch. ie., you want the real ingress device there not > the vrf device.

Re: [PATCH] net: VRF: Fix receiving multicast traffic

2016-09-22 Thread David Ahern
On 9/21/16 10:13 PM, Mark Tomlinson wrote: > The previous patch to ensure that the original iif was used when > checking for forwarding also meant that this same interface was used to > determine whether multicast packets should be received or not. This was > incorrect, and would cause multicast pa

[PATCH] net: VRF: Fix receiving multicast traffic

2016-09-21 Thread Mark Tomlinson
The previous patch to ensure that the original iif was used when checking for forwarding also meant that this same interface was used to determine whether multicast packets should be received or not. This was incorrect, and would cause multicast packets to be dropped. The fix here is to use skb->d