[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c4a22424-9f4f-cbc2-8fb8-292c1501e875@gmail.com>
Date: Tue, 25 Jun 2019 14:52:17 -0600
From: David Ahern <dsahern@...il.com>
To: Stephen Suryaputra <ssuryaextr@...il.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
On 6/25/19 2:42 PM, Stephen Suryaputra wrote:
> On Tue, Jun 25, 2019 at 4:22 PM David Ahern <dsahern@...il.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.
Powered by blists - more mailing lists