mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Logical bug in ipv4 (and ipv6?) PMTU handling?
@ 2003-06-12 20:11 Harald   Nordgård-Hansen
  2003-06-13  0:14 ` David S. Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Harald   Nordgård-Hansen @ 2003-06-12 20:11 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

I was helping a collegue here trying to get some udp packets through a
link, and stumbled upon what seems to be a bug in the ipv4 code of
current kernels (checked 2.4.20, 2.4.21-pre8 and 2.5.70).

According to 'man 7 ip', the IP_PMTU_DISCOVER flag i controlled by the
ip_no_pmtu_disc sysctl for SOCK_STREAM, and off for all other socket
types.  But in net/ipv4/af_inet.c, the flag is set based on
ip_no_pmtu_disc, regardless of socket type.

This causes all udp packets to be send out with the ip don't fragment
flag set, and unless the application happens to handle the resulting
error messages generated, the packets will not get through on
lower-mtu path segments.  A quick dump of some udp packets confirms
that the don't fragment flag is set on all the packets.

The attached one-liner will limit setting IP_PMTU_DISCOVER on sockets
to only those of the SOCK_STREAM type, which is what the documentation
says should happen (as would be logical, as other sockets need the
application to explicitly handle the size adjustments).  It should
apply cleanly to 2.4.20 and 2.4.21-pre8, and shouldn't be hard to
adapt to 2.5.x.

I don't know enough about ipv6 to understand if this behaviour should
be the same there, but net/ipv6/af_inet6.c contains mostly the same
logic, and should probably be fixed as well.

-Harald
-- 
Harald Nordgård-Hansen, Linpro AS <>< http://harald.nordgard-hansen.net/
Pancoveien 7, NO-1624 Gressvik, Norway  ><>  Phone/Fax: +47 6935 2424/25

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: IP_PMTU_DISCOVER fix for af_inet.c --]
[-- Type: text/x-patch, Size: 393 bytes --]

--- net/ipv4/af_inet.c.orig	2003-06-12 21:18:05.000000000 +0200
+++ net/ipv4/af_inet.c	2003-06-12 21:18:41.000000000 +0200
@@ -369,7 +369,7 @@
 			sk->protinfo.af_inet.hdrincl = 1;
 	}
 
-	if (ipv4_config.no_pmtu_disc)
+	if (SOCK_STREAM != sock->type || ipv4_config.no_pmtu_disc)
 		sk->protinfo.af_inet.pmtudisc = IP_PMTUDISC_DONT;
 	else
 		sk->protinfo.af_inet.pmtudisc = IP_PMTUDISC_WANT;

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

* Re: Logical bug in ipv4 (and ipv6?) PMTU handling?
  2003-06-12 20:11 Logical bug in ipv4 (and ipv6?) PMTU handling? Harald   Nordgård-Hansen
@ 2003-06-13  0:14 ` David S. Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David S. Miller @ 2003-06-13  0:14 UTC (permalink / raw)
  To: Harald Nordgård-Hansen; +Cc: linux-kernel

On Thu, 2003-06-12 at 13:11, Harald Nordgård-Hansen wrote:
> I was helping a collegue here trying to get some udp packets through a
> link, and stumbled upon what seems to be a bug in the ipv4 code of
> current kernels (checked 2.4.20, 2.4.21-pre8 and 2.5.70).

It's not a bug, we do UDP path mtu discovery on purpose.

-- 
David S. Miller <davem@redhat.com>

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

end of thread, other threads:[~2003-06-13  0:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-12 20:11 Logical bug in ipv4 (and ipv6?) PMTU handling? Harald   Nordgård-Hansen
2003-06-13  0:14 ` David S. Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®