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
*/
next prev parent 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).