[lkml]   [2001]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Problem with PMTU discovery on ICMP packets
> From: David S. Miller []

> I want to understand why on some boots it's on while on some
> boots it is off, that makes no sense.
> Before the piece of code you patched, we call ops->create() which is
> inet_create in net/ipv4/af_inet.c, there is sets the PMTU discovery
> disposition based upon the setting in ipv4_config which should always
> have the same setting at the point during boot, every boot.
> You need to figure out why it sometimes gets set and sometimes does
> not, then we can figure out how to fix it.

Yes, I see your point. I guess I made an incorrect assumption about it
being changed between reboots. It could be related to routing or something
instead. I'll have to dig a bit further to find a pattern.

However, even if I *do* find the pattern, I still think it is reasonable
to turn off PMTU discovery for ICMP explicitly, instead of based on the
setting of ipv4_config:

1) The setting for the one global ICMP socket gets set once and for all
at initialization time and doesn't track the setting of ip_no_pmtu_disc.

2) Even if it *did* track ip_no_pmtu_disc, the missing per-protocol
granularity of ip_no_pmtu_disc means that you couldn't have PMTU discovery
enabled for TCP, while having it disabled for ICMP.

3) I don't see any reason for wanting to do automatic PMTU discovery for
ICMP packets; normally they are only sent once, and you'll risk it being
dropped somewhere along its path if the DF bit is set.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.046 / U:1.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site