netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net 0/2] ip[6] tunnels: fix mtu calculations
@ 2018-05-30  8:28 Nicolas Dichtel
  2018-05-30  8:28 ` [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
  2018-05-30  8:28 ` [PATCH net 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel
  0 siblings, 2 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-30  8:28 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev


The first patch restores the possibility to bind an ip4 tunnel to an
interface whith a large mtu.
The second patch was spotted after the first fix. I also target it to net
because it fixes the max mtu value that can be used for ipv6 tunnels.

 net/ipv4/ip_tunnel.c  |  6 +++---
 net/ipv6/ip6_tunnel.c | 11 ++++++++---
 net/ipv6/sit.c        |  5 +++--
 3 files changed, 14 insertions(+), 8 deletions(-)

Comments are welcomed,
Regards,
Nicolas

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu
  2018-05-30  8:28 [PATCH net 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
@ 2018-05-30  8:28 ` Nicolas Dichtel
  2018-05-30 20:29   ` Ido Schimmel
  2018-05-30  8:28 ` [PATCH net 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel
  1 sibling, 1 reply; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-30  8:28 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel

After commit f6cc9c054e77, the following conf is broken (note that the
default loopback mtu is 65536, ie IP_MAX_MTU + 1):

$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev lo
add tunnel "gre0" failed: Invalid argument
$ ip l a type dummy
$ ip l s dummy1 up
$ ip l s dummy1 mtu 65535
$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev dummy1
add tunnel "gre0" failed: Invalid argument

dev_set_mtu() doesn't allow to set a mtu which is too large.
First, let's cap the mtu returned by ip_tunnel_bind_dev(). Second, remove
the magic value 0xFFF8 and use IP_MAX_MTU instead.
0xFFF8 seems to be there for ages, I don't know why this value was used.

With a recent kernel, it's also possible to set a mtu > IP_MAX_MTU:
$ ip l s dummy1 mtu 66000
After that patch, it's also possible to bind an ip tunnel on that kind of
interface.

CC: Petr Machata <petrm@mellanox.com>
CC: Ido Schimmel <idosch@mellanox.com>
Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Fixes: f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 net/ipv4/ip_tunnel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 6b0e362cc99b..3b39c72a1029 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -328,7 +328,7 @@ static int ip_tunnel_bind_dev(struct net_device *dev)
 
 	if (tdev) {
 		hlen = tdev->hard_header_len + tdev->needed_headroom;
-		mtu = tdev->mtu;
+		mtu = min(tdev->mtu, IP_MAX_MTU);
 	}
 
 	dev->needed_headroom = t_hlen + hlen;
@@ -362,7 +362,7 @@ static struct ip_tunnel *ip_tunnel_create(struct net *net,
 	nt = netdev_priv(dev);
 	t_hlen = nt->hlen + sizeof(struct iphdr);
 	dev->min_mtu = ETH_MIN_MTU;
-	dev->max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+	dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
 	ip_tunnel_add(itn, nt);
 	return nt;
 
@@ -930,7 +930,7 @@ int __ip_tunnel_change_mtu(struct net_device *dev, int new_mtu, bool strict)
 {
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	int t_hlen = tunnel->hlen + sizeof(struct iphdr);
-	int max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+	int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
 
 	if (new_mtu < ETH_MIN_MTU)
 		return -EINVAL;
-- 
2.15.1

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH net 2/2] ip6_tunnel: remove magic mtu value 0xFFF8
  2018-05-30  8:28 [PATCH net 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
  2018-05-30  8:28 ` [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
@ 2018-05-30  8:28 ` Nicolas Dichtel
  1 sibling, 0 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-30  8:28 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel

I don't know where this value comes from (probably a copy and paste and
paste and paste ...).
Let's use standard values which are a bit greater.

Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 net/ipv6/ip6_tunnel.c | 11 ++++++++---
 net/ipv6/sit.c        |  5 +++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index da66aaac51ce..00e138a44cbb 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1692,8 +1692,13 @@ int ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
 		if (new_mtu < ETH_MIN_MTU)
 			return -EINVAL;
 	}
-	if (new_mtu > 0xFFF8 - dev->hard_header_len)
-		return -EINVAL;
+	if (tnl->parms.proto == IPPROTO_IPV6 || tnl->parms.proto == 0) {
+		if (new_mtu > IP6_MAX_MTU - dev->hard_header_len)
+			return -EINVAL;
+	} else {
+		if (new_mtu > IP_MAX_MTU - dev->hard_header_len)
+			return -EINVAL;
+	}
 	dev->mtu = new_mtu;
 	return 0;
 }
@@ -1841,7 +1846,7 @@ ip6_tnl_dev_init_gen(struct net_device *dev)
 	if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
 		dev->mtu -= 8;
 	dev->min_mtu = ETH_MIN_MTU;
-	dev->max_mtu = 0xFFF8 - dev->hard_header_len;
+	dev->max_mtu = IP6_MAX_MTU - dev->hard_header_len;
 
 	return 0;
 
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 2afce37a7177..e9400ffa7875 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1371,7 +1371,7 @@ static void ipip6_tunnel_setup(struct net_device *dev)
 	dev->hard_header_len	= LL_MAX_HEADER + t_hlen;
 	dev->mtu		= ETH_DATA_LEN - t_hlen;
 	dev->min_mtu		= IPV6_MIN_MTU;
-	dev->max_mtu		= 0xFFF8 - t_hlen;
+	dev->max_mtu		= IP6_MAX_MTU - t_hlen;
 	dev->flags		= IFF_NOARP;
 	netif_keep_dst(dev);
 	dev->addr_len		= 4;
@@ -1583,7 +1583,8 @@ static int ipip6_newlink(struct net *src_net, struct net_device *dev,
 	if (tb[IFLA_MTU]) {
 		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
 
-		if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+		if (mtu >= IPV6_MIN_MTU &&
+		    mtu <= IP6_MAX_MTU - dev->hard_header_len)
 			dev->mtu = mtu;
 	}
 
-- 
2.15.1

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu
  2018-05-30  8:28 ` [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
@ 2018-05-30 20:29   ` Ido Schimmel
  2018-05-31  8:52     ` Nicolas Dichtel
  2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
  0 siblings, 2 replies; 10+ messages in thread
From: Ido Schimmel @ 2018-05-30 20:29 UTC (permalink / raw)
  To: Nicolas Dichtel; +Cc: davem, petrm, idosch, netdev

On Wed, May 30, 2018 at 10:28:42AM +0200, Nicolas Dichtel wrote:
> After commit f6cc9c054e77, the following conf is broken (note that the
> default loopback mtu is 65536, ie IP_MAX_MTU + 1):
> 
> $ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev lo
> add tunnel "gre0" failed: Invalid argument
> $ ip l a type dummy
> $ ip l s dummy1 up
> $ ip l s dummy1 mtu 65535
> $ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev dummy1
> add tunnel "gre0" failed: Invalid argument
> 
> dev_set_mtu() doesn't allow to set a mtu which is too large.
> First, let's cap the mtu returned by ip_tunnel_bind_dev(). Second, remove
> the magic value 0xFFF8 and use IP_MAX_MTU instead.
> 0xFFF8 seems to be there for ages, I don't know why this value was used.
> 
> With a recent kernel, it's also possible to set a mtu > IP_MAX_MTU:
> $ ip l s dummy1 mtu 66000
> After that patch, it's also possible to bind an ip tunnel on that kind of
> interface.
> 
> CC: Petr Machata <petrm@mellanox.com>
> CC: Ido Schimmel <idosch@mellanox.com>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
> Fixes: f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Reviewed-by: Ido Schimmel <idosch@mellanox.com>

There is another instance of this magic number in the file, but it's
written in lower case so you might have missed it - see
ip_tunnel_newlink(). Can you please take care of it in v2?

Thanks for the fix, Nicolas!

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu
  2018-05-30 20:29   ` Ido Schimmel
@ 2018-05-31  8:52     ` Nicolas Dichtel
  2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
  1 sibling, 0 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-31  8:52 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: davem, petrm, idosch, netdev

Le 30/05/2018 à 22:29, Ido Schimmel a écrit :
[snip]
> There is another instance of this magic number in the file, but it's
> written in lower case so you might have missed it - see
> ip_tunnel_newlink(). Can you please take care of it in v2?
Good catch, thank you.
Will send a v2.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations
  2018-05-30 20:29   ` Ido Schimmel
  2018-05-31  8:52     ` Nicolas Dichtel
@ 2018-05-31  8:59     ` Nicolas Dichtel
  2018-05-31  8:59       ` [PATCH net v2 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
                         ` (2 more replies)
  1 sibling, 3 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-31  8:59 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev


The first patch restores the possibility to bind an ip4 tunnel to an
interface whith a large mtu.
The second patch was spotted after the first fix. I also target it to net
because it fixes the max mtu value that can be used for ipv6 tunnels.

v2: remove the 0xfff8 in ip_tunnel_newlink()

 net/ipv4/ip_tunnel.c  |  8 ++++----
 net/ipv6/ip6_tunnel.c | 11 ++++++++---
 net/ipv6/sit.c        |  5 +++--
 3 files changed, 15 insertions(+), 9 deletions(-)

Comments are welcomed,
Regards,
Nicolas

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH net v2 1/2] ip_tunnel: restore binding to ifaces with a large mtu
  2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
@ 2018-05-31  8:59       ` Nicolas Dichtel
  2018-05-31  8:59       ` [PATCH net v2 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel
  2018-06-01 17:57       ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations David Miller
  2 siblings, 0 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-31  8:59 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel

After commit f6cc9c054e77, the following conf is broken (note that the
default loopback mtu is 65536, ie IP_MAX_MTU + 1):

$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev lo
add tunnel "gre0" failed: Invalid argument
$ ip l a type dummy
$ ip l s dummy1 up
$ ip l s dummy1 mtu 65535
$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev dummy1
add tunnel "gre0" failed: Invalid argument

dev_set_mtu() doesn't allow to set a mtu which is too large.
First, let's cap the mtu returned by ip_tunnel_bind_dev(). Second, remove
the magic value 0xFFF8 and use IP_MAX_MTU instead.
0xFFF8 seems to be there for ages, I don't know why this value was used.

With a recent kernel, it's also possible to set a mtu > IP_MAX_MTU:
$ ip l s dummy1 mtu 66000
After that patch, it's also possible to bind an ip tunnel on that kind of
interface.

CC: Petr Machata <petrm@mellanox.com>
CC: Ido Schimmel <idosch@mellanox.com>
Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Fixes: f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
---
 net/ipv4/ip_tunnel.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 6b0e362cc99b..38d906baf1df 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -328,7 +328,7 @@ static int ip_tunnel_bind_dev(struct net_device *dev)
 
 	if (tdev) {
 		hlen = tdev->hard_header_len + tdev->needed_headroom;
-		mtu = tdev->mtu;
+		mtu = min(tdev->mtu, IP_MAX_MTU);
 	}
 
 	dev->needed_headroom = t_hlen + hlen;
@@ -362,7 +362,7 @@ static struct ip_tunnel *ip_tunnel_create(struct net *net,
 	nt = netdev_priv(dev);
 	t_hlen = nt->hlen + sizeof(struct iphdr);
 	dev->min_mtu = ETH_MIN_MTU;
-	dev->max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+	dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
 	ip_tunnel_add(itn, nt);
 	return nt;
 
@@ -930,7 +930,7 @@ int __ip_tunnel_change_mtu(struct net_device *dev, int new_mtu, bool strict)
 {
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	int t_hlen = tunnel->hlen + sizeof(struct iphdr);
-	int max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+	int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
 
 	if (new_mtu < ETH_MIN_MTU)
 		return -EINVAL;
@@ -1107,7 +1107,7 @@ int ip_tunnel_newlink(struct net_device *dev, struct nlattr *tb[],
 
 	mtu = ip_tunnel_bind_dev(dev);
 	if (tb[IFLA_MTU]) {
-		unsigned int max = 0xfff8 - dev->hard_header_len - nt->hlen;
+		unsigned int max = IP_MAX_MTU - dev->hard_header_len - nt->hlen;
 
 		mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
 			    (unsigned int)(max - sizeof(struct iphdr)));
-- 
2.15.1

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH net v2 2/2] ip6_tunnel: remove magic mtu value 0xFFF8
  2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
  2018-05-31  8:59       ` [PATCH net v2 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
@ 2018-05-31  8:59       ` Nicolas Dichtel
  2018-06-01 17:57       ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations David Miller
  2 siblings, 0 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-05-31  8:59 UTC (permalink / raw)
  To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel

I don't know where this value comes from (probably a copy and paste and
paste and paste ...).
Let's use standard values which are a bit greater.

Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 net/ipv6/ip6_tunnel.c | 11 ++++++++---
 net/ipv6/sit.c        |  5 +++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index da66aaac51ce..00e138a44cbb 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1692,8 +1692,13 @@ int ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
 		if (new_mtu < ETH_MIN_MTU)
 			return -EINVAL;
 	}
-	if (new_mtu > 0xFFF8 - dev->hard_header_len)
-		return -EINVAL;
+	if (tnl->parms.proto == IPPROTO_IPV6 || tnl->parms.proto == 0) {
+		if (new_mtu > IP6_MAX_MTU - dev->hard_header_len)
+			return -EINVAL;
+	} else {
+		if (new_mtu > IP_MAX_MTU - dev->hard_header_len)
+			return -EINVAL;
+	}
 	dev->mtu = new_mtu;
 	return 0;
 }
@@ -1841,7 +1846,7 @@ ip6_tnl_dev_init_gen(struct net_device *dev)
 	if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
 		dev->mtu -= 8;
 	dev->min_mtu = ETH_MIN_MTU;
-	dev->max_mtu = 0xFFF8 - dev->hard_header_len;
+	dev->max_mtu = IP6_MAX_MTU - dev->hard_header_len;
 
 	return 0;
 
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 2afce37a7177..e9400ffa7875 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1371,7 +1371,7 @@ static void ipip6_tunnel_setup(struct net_device *dev)
 	dev->hard_header_len	= LL_MAX_HEADER + t_hlen;
 	dev->mtu		= ETH_DATA_LEN - t_hlen;
 	dev->min_mtu		= IPV6_MIN_MTU;
-	dev->max_mtu		= 0xFFF8 - t_hlen;
+	dev->max_mtu		= IP6_MAX_MTU - t_hlen;
 	dev->flags		= IFF_NOARP;
 	netif_keep_dst(dev);
 	dev->addr_len		= 4;
@@ -1583,7 +1583,8 @@ static int ipip6_newlink(struct net *src_net, struct net_device *dev,
 	if (tb[IFLA_MTU]) {
 		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
 
-		if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+		if (mtu >= IPV6_MIN_MTU &&
+		    mtu <= IP6_MAX_MTU - dev->hard_header_len)
 			dev->mtu = mtu;
 	}
 
-- 
2.15.1

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations
  2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
  2018-05-31  8:59       ` [PATCH net v2 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
  2018-05-31  8:59       ` [PATCH net v2 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel
@ 2018-06-01 17:57       ` David Miller
  2018-06-04  7:56         ` Nicolas Dichtel
  2 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2018-06-01 17:57 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: petrm, idosch, netdev

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 31 May 2018 10:59:31 +0200

> The first patch restores the possibility to bind an ip4 tunnel to an
> interface whith a large mtu.
> The second patch was spotted after the first fix. I also target it to net
> because it fixes the max mtu value that can be used for ipv6 tunnels.
> 
> v2: remove the 0xfff8 in ip_tunnel_newlink()

Series applied and queued up for -stable.

I think the 0xfff8 value might come from the requirement that ipv6
fragments need to be a multiple of 8 bytes long.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations
  2018-06-01 17:57       ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations David Miller
@ 2018-06-04  7:56         ` Nicolas Dichtel
  0 siblings, 0 replies; 10+ messages in thread
From: Nicolas Dichtel @ 2018-06-04  7:56 UTC (permalink / raw)
  To: David Miller; +Cc: petrm, idosch, netdev

Le 01/06/2018 à 19:57, David Miller a écrit :
[snip]
> I think the 0xfff8 value might come from the requirement that ipv6
> fragments need to be a multiple of 8 bytes long.
> 
Oh, thanks for the explanation!

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-06-04  7:56 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-30  8:28 [PATCH net 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
2018-05-30  8:28 ` [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
2018-05-30 20:29   ` Ido Schimmel
2018-05-31  8:52     ` Nicolas Dichtel
2018-05-31  8:59     ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations Nicolas Dichtel
2018-05-31  8:59       ` [PATCH net v2 1/2] ip_tunnel: restore binding to ifaces with a large mtu Nicolas Dichtel
2018-05-31  8:59       ` [PATCH net v2 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel
2018-06-01 17:57       ` [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations David Miller
2018-06-04  7:56         ` Nicolas Dichtel
2018-05-30  8:28 ` [PATCH net 2/2] ip6_tunnel: remove magic mtu value 0xFFF8 Nicolas Dichtel

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).