On 6/25/19 2:42 PM, Stephen Suryaputra wrote:
> On Tue, Jun 25, 2019 at 4:22 PM David Ahern <dsah...@gmail.com> wrote:
>>
>> On 6/25/19 4:33 AM, Stephen Suryaputra wrote:
>>> @@ -363,10 +376,20 @@ int ip_mc_output(struct net *net, struct sock *sk,
>>> struct sk_buff *skb)
>>> #endif
>>> ) {
>>> struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
>>> - if (newskb)
>>> + if (newskb) {
>>> + /* Reset rt_iif so that inet_iif() will return
>>> + * skb->dev->ifIndex which is the VRF device
>>> for
>>> + * socket lookup. Setting this to VRF ifindex
>>> + * causes ipi_ifindex in in_pktinfo to be
>>> + * overwritten, see ipv4_pktinfo_prepare().
>>> + */
>>> + if (netif_is_l3_slave(dev))
>>
>> seems like the rt_iif is a problem for recirculated mcast packets in
>> general, not just ones tied to a VRF.
>
> It seems so to me too but I wonder why this hasn't been seen...
> Can I get more feedbacks on this? If there is an agreement to fix this
> generally, I will remove the if clause and respin the patch with more
> accurate changelog.
rt_iif is used to save the original oif during a route lookup so if
packets are delivered locally apps can know the real oif and not the
loopback/VRF device which is just a trick for local traffic.
The raw socket lookup was recently changed to handle local traffic with
raw sockets bound to a device. e.g., ping was recently changed to use
SO_BINDTODEVICE vs IP_PKTINFO and revealed that the socket lookup was
not considering rt_iif when doing the lookup for 'ping -I <dev> <dev addr>'
The mcast use case seems to get hung up on rt_iif being set when packets
are recirculated for local delivery which is slightly different use case
than local traffic to local addresses.
