netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Friesen <chris.friesen@windriver.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev <netdev@vger.kernel.org>
Subject: [PATCH v2] route: do not cache fib route info on local routes with oif
Date: Fri, 8 Apr 2016 09:08:00 -0600	[thread overview]
Message-ID: <5707C950.6060806@windriver.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1604072305400.2154@ja.home.ssi.bg>

For local routes that require a particular output interface we do not want to
cache the result.  Caching the result causes incorrect behaviour when there are
multiple source addresses on the interface.  The end result being that if the
intended recipient is waiting on that interface for the packet he won't receive
it because it will be delivered on the loopback interface and the IP_PKTINFO
ipi_ifindex will be set to the loopback interface as well.

This can be tested by running a program such as "dhcp_release" which attempts
to inject a packet on a particular interface so that it is received by another
program on the same board.  The receiving process should see an IP_PKTINFO
ipi_ifndex value of the source interface (e.g., eth1) instead of the loopback
interface (e.g., lo).  The packet will still appear on the loopback interface
in tcpdump but the important aspect is that the CMSG info is correct.

Sample dhcp_release command line:

    dhcp_release eth1 192.168.204.222 02:11:33:22:44:66

Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
Signed off-by: Chris Friesen <chris.friesen@windriver.com>
---
  net/ipv4/route.c | 12 ++++++++++++
  1 file changed, 12 insertions(+)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 02c6229..437a377 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2045,6 +2045,18 @@ static struct rtable *__mkroute_output(const struct 
fib_result *res,
  		 */
  		if (fi && res->prefixlen < 4)
  			fi = NULL;
+	} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
+		   (orig_oif != dev_out->ifindex)) {
+		/* For local routes that require a particular output interface
+		 * we do not want to cache the result.  Caching the result
+		 * causes incorrect behaviour when there are multiple source
+		 * addresses on the interface, the end result being that if the
+		 * intended recipient is waiting on that interface for the
+		 * packet he won't receive it because it will be delivered on
+		 * the loopback interface and the IP_PKTINFO ipi_ifindex will
+		 * be set to the loopback interface as well.
+		 */
+		fi = NULL;
  	}

  	fnhe = NULL;

  parent reply	other threads:[~2016-04-08 15:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 19:17 [RFC PATCH] possible bug in handling of ipv4 route caching Chris Friesen
2016-04-07 21:20 ` Julian Anastasov
2016-04-08 15:00   ` Chris Friesen
2016-04-08 15:08   ` Chris Friesen [this message]
2016-04-08 19:14     ` [PATCH v2] route: do not cache fib route info on local routes with oif Julian Anastasov
2016-04-08 20:06       ` Chris Friesen
2016-04-08 20:07       ` [PATCH v3] " Chris Friesen
2016-04-08 20:35         ` Julian Anastasov
2016-04-08 21:21           ` [PATCH v4] " Chris Friesen
2016-04-08 22:08             ` Julian Anastasov
2016-04-14  3:34             ` David Miller

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=5707C950.6060806@windriver.com \
    --to=chris.friesen@windriver.com \
    --cc=ja@ssi.bg \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).