Commit 734d2725 authored Aug 18, 2013 by Eric Dumazet Committed by David S. Miller Aug 20, 2013

ipv4: raise IP_MAX_MTU to theoretical limit

As discussed last year [1], there is no compelling reason
to limit IPv4 MTU to 0xFFF0, while real limit is 0xFFFF

[1] : http://marc.info/?l=linux-netdev&m=135607247609434&w=2



Willem raised this issue again because some of our internal
regression tests broke after lo mtu being set to 65536.

IP_MTU reports 0xFFF0, and the test attempts to send a RAW datagram of
mtu + 1 bytes, expecting the send() to fail, but it does not.

Alexey raised interesting points about TCP MSS, that should be addressed
in follow-up patches in TCP stack if needed, as someone could also set
an odd mtu anyway.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

parent 35596b27

net/ipv4/route.c

+3 −5

Original line number	Diff line number	Diff line
		@@ -112,7 +112,8 @@
		#define RT_FL_TOS(oldflp4) \
		((oldflp4)->flowi4_tos & (IPTOS_RT_MASK \| RTO_ONLINK))

		#define IP_MAX_MTU 0xFFF0
		/* IPv4 datagram length is stored into 16bit field (tot_len) */
		#define IP_MAX_MTU 0xFFFF

		#define RT_GC_TIMEOUT (300*HZ)

		@@ -1227,10 +1228,7 @@ static unsigned int ipv4_mtu(const struct dst_entry *dst)
		mtu = 576;
		}

		if (mtu > IP_MAX_MTU)
		mtu = IP_MAX_MTU;

		return mtu;
		return min_t(unsigned int, mtu, IP_MAX_MTU);
		}

		static struct fib_nh_exception find_exception(struct fib_nh nh, __be32 daddr)