netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Colitti <lorenzo@google.com>
To: David Miller <davem@davemloft.net>
Cc: zenczykowski@gmail.com, therbert@google.com, netdev@vger.kernel.org
Subject: Re: [PATCH] IPv6: fix rt_lookup in pmtu_discovery
Date: Fri, 8 Jan 2010 16:12:55 -0800	[thread overview]
Message-ID: <b91784ff1001081612g7c15e968u5e77931289af25c@mail.gmail.com> (raw)
In-Reply-To: <20100107.171015.29035630.davem@davemloft.net>

2010/1/7 David Miller <davem@davemloft.net>
>    ipv4: Update MTU to all related cache entries in ip_rt_frag_needed()
>
>    Add struct net_device parameter to ip_rt_frag_needed() and update MTU to
>    cache entries where ifindex is specified. This is similar to what is
>    already done in ip_rt_redirect().
> [...]
> +       int  ikeys[2] = { dev->ifindex, 0 };
>        __be32  skeys[2] = { iph->saddr, 0, };
>        __be32  daddr = iph->daddr;
> [...]

That patch makes it so that if a fragmentation needed message is
received on an interface other than the one that the kernel would
normally use to send a message to the original destination, then any
route cache entries pointing out that interface are updated as well.
AFAICT it was motivated by a scenario where traffic  was intended to
be sent through a particular interface with SO_BINDTODEVICE set:
http://lists.openwall.net/netdev/2008/04/24/44

The correct thing to do would be to update the MTU on all the route
cache entries, including entries pointing to other interfaces on the
box (for example, consider a box with a default route pointing at
eth0, the packet too big coming in on eth1, and the original packet
having been sent through gre1 with SO_BINDTODEVICE; in this case, the
existing IPv4 code would silently fail). However, this is expensive
and doing it for the two common cases seems a reasonable compromise,
so it's probably worth doing it for IPv6 as well.

How about this patch instead?

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c2bd74c..c27464d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1562,14 +1562,13 @@ out:
  *	i.e. Path MTU discovery
  */

-void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
-			struct net_device *dev, u32 pmtu)
+static void rt6_do_pmtu_disc(struct in6_addr *daddr, struct in6_addr *saddr,
+			     struct net *net, u32 pmtu, int ifindex)
 {
 	struct rt6_info *rt, *nrt;
-	struct net *net = dev_net(dev);
 	int allfrag = 0;

-	rt = rt6_lookup(net, daddr, saddr, dev->ifindex, 0);
+	rt = rt6_lookup(net, daddr, saddr, ifindex, 0);
 	if (rt == NULL)
 		return;

@@ -1637,6 +1636,28 @@ out:
 	dst_release(&rt->u.dst);
 }

+void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
+			struct net_device *dev, u32 pmtu)
+{
+	struct net *net = dev_net(dev);
+
+	/*
+	 * RFC 1981 states that a node "MUST reduce the size of the packets it
+	 * is sending along the path" that caused the Packet Too Big message.
+	 * Since it's not possible in the general case to determine which
+	 * interface was used to send the original packet, we update the MTU
+	 * on the interface that will be used to send future packets. We also
+	 * update the MTU on the interface that received the Packet Too Big in
+	 * case the original packet was forced out that interface with
+	 * SO_BINDTODEVICE or similar. This is the next best thing to the
+	 * correct behaviour, which would be to update the MTU on all
+	 * interfaces.
+	 */
+	rt6_do_pmtu_disc(daddr, saddr, net, pmtu, 0);
+	rt6_do_pmtu_disc(daddr, saddr, net, pmtu, dev->ifindex);
+}
+
+
 /*
  *	Misc support functions
  */

  reply	other threads:[~2010-01-09  0:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-07  4:43 [PATCH] IPv6: fix rt_lookup in pmtu_discovery Tom Herbert
2010-01-07  9:27 ` David Miller
2010-01-08  1:05   ` Maciej Żenczykowski
2010-01-08  1:10     ` David Miller
2010-01-09  0:12       ` Lorenzo Colitti [this message]
2010-01-10 21:15         ` David Miller
2010-01-14  0:51           ` Maciej Żenczykowski
2010-01-20 22:55             ` Maciej Żenczykowski
2010-01-20 22:57               ` David Miller
2010-01-20 23:33                 ` Maciej Żenczykowski
2010-01-23 10:20             ` David Miller
2010-09-27 10:05             ` [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes Maciej Żenczykowski
     [not found]               ` <AANLkTikPOHy79E1ZG=iJ-rHj0vzS+AY-mGqCEtWoXp2o@mail.gmail.com>
2010-09-27 18:11                 ` David Miller
2010-09-28 20:58               ` David Miller
2010-09-28 22:37                 ` Maciej Żenczykowski
2010-09-30  7:41                   ` David Miller
2010-10-03 21:49                     ` David Miller
2010-10-04  0:21                       ` Maciej Żenczykowski

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=b91784ff1001081612g7c15e968u5e77931289af25c@mail.gmail.com \
    --to=lorenzo@google.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=therbert@google.com \
    --cc=zenczykowski@gmail.com \
    /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).