Messages in this thread |  | | From | "Svenning Soerensen" <> | Subject | RE: Problem with PMTU discovery on ICMP packets | Date | Sat, 5 May 2001 16:23:18 +0200 |
| |
> From: David S. Miller [mailto:davem@redhat.com]
> 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.
Svenning - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |