All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	David Ahern <dsahern@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org,
	Hideaki Yoshifuji <hideaki.yoshifuji@miraclelinux.com>
Subject: Re: [PATCH 3/3] ipv6/icmp: l3mdev: Perform icmp error route lookup on source device routing table
Date: Thu, 13 Aug 2020 17:21:55 -0600	[thread overview]
Message-ID: <2adc1bd3-53aa-0f3e-d5e4-740d11098685@gmail.com> (raw)
In-Reply-To: <20200811195003.1812-4-mathieu.desnoyers@efficios.com>

On 8/11/20 1:50 PM, Mathieu Desnoyers wrote:
> As per RFC4443, the destination address field for ICMPv6 error messages
> is copied from the source address field of the invoking packet.
> 
> In configurations with Virtual Routing and Forwarding tables, looking up
> which routing table to use for sending ICMPv6 error messages is
> currently done by using the destination net_device.
> 
> If the source and destination interfaces are within separate VRFs, or
> one in the global routing table and the other in a VRF, looking up the
> source address of the invoking packet in the destination interface's
> routing table will fail if the destination interface's routing table
> contains no route to the invoking packet's source address.
> 
> One observable effect of this issue is that traceroute6 does not work in
> the following cases:
> 
> - Route leaking between global routing table and VRF
> - Route leaking between VRFs
> 
> Preferably use the source device routing table when sending ICMPv6 error
> messages. If no source device is set, fall-back on the destination
> device routing table.
> 
> Link: https://tools.ietf.org/html/rfc4443
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: David Ahern <dsahern@kernel.org>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> ---
>  net/ipv6/icmp.c       | 15 +++++++++++++--
>  net/ipv6/ip6_output.c |  2 --
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
> index a4e4912ad607..a971b58b0371 100644
> --- a/net/ipv6/icmp.c
> +++ b/net/ipv6/icmp.c
> @@ -501,8 +501,19 @@ void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info,
>  	if (__ipv6_addr_needs_scope_id(addr_type)) {
>  		iif = icmp6_iif(skb);
>  	} else {
> -		dst = skb_dst(skb);
> -		iif = l3mdev_master_ifindex(dst ? dst->dev : skb->dev);
> +		struct net_device *route_lookup_dev = NULL;
> +
> +		/*
> +		 * The device used for looking up which routing table to use is
> +		 * preferably the source whenever it is set, which should
> +		 * ensure the icmp error can be sent to the source host, else
> +		 * fallback on the destination device.
> +		 */
> +		if (skb->dev)
> +			route_lookup_dev = skb->dev;

top of icmp6_send there is a check that skb->dev is set.


> +		else if (skb_dst(skb))
> +			route_lookup_dev = skb_dst(skb)->dev;
> +		iif = l3mdev_master_ifindex(route_lookup_dev);
>  	}
>  
>  	/*
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index c78e67d7747f..cd623068de53 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -468,8 +468,6 @@ int ip6_forward(struct sk_buff *skb)
>  	 *	check and decrement ttl
>  	 */
>  	if (hdr->hop_limit <= 1) {
> -		/* Force OUTPUT device used as source address */
> -		skb->dev = dst->dev;

I *think* this ok. Not clear to me why the forward path would change the
skb->dev like that. Goes back to beginning of the git history.

>  		icmpv6_send(skb, ICMPV6_TIME_EXCEED, ICMPV6_EXC_HOPLIMIT, 0);
>  		__IP6_INC_STATS(net, idev, IPSTATS_MIB_INHDRERRORS);
>  
> 


      reply	other threads:[~2020-08-13 23:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 19:50 [PATCH 0/3] l3mdev icmp error route lookup fixes Mathieu Desnoyers
2020-08-11 19:50 ` [PATCH 1/3] selftests: Add VRF icmp error route lookup test Mathieu Desnoyers
2020-08-13 23:13   ` David Ahern
2020-08-14 14:05     ` Michael Jeanson
2020-08-11 19:50 ` [PATCH 2/3] ipv4/icmp: l3mdev: Perform icmp error route lookup on source device routing table Mathieu Desnoyers
2020-08-12 21:43   ` David Miller
2020-08-13 13:12     ` Mathieu Desnoyers
2020-08-13 22:59   ` David Ahern
2020-08-11 19:50 ` [PATCH 3/3] ipv6/icmp: " Mathieu Desnoyers
2020-08-13 23:21   ` David Ahern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2adc1bd3-53aa-0f3e-d5e4-740d11098685@gmail.com \
    --to=dsahern@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=hideaki.yoshifuji@miraclelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.