All of lore.kernel.org
 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 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.