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
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
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
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.
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
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