This does not make much sense. For what do you need the large MTU ?
If you lie to the stack about the MTU you'll only have to duplicate
some work it'll otherwise do for you (like sending the ICMP or using
reasonable initial MSS). And what gain would that duplicate work
give you? Nothing.
Fragmentation on the IPSec level is not interesting anyways, because
it is rather useless:
In transport mode DF will be near
always set because TCP does path mtu discovery. You first set the MTU
of your virtual device (or whatever implementation transport mode IPSec will
chose) so that it starts with the correct MTU, if it doesn't workout
for some reason [e.g. because the effective MTU changed] you use
the error queue [ip_local_error] to inform TCP and the destination
caache about the new MTU. This only works for shrinking MTUs, not increasing
them ATM, in case this should be important for IPSec it can be added.
For transport mode UDP it is similar, either the stack will fragment
for you automagically, or the application will use the pmtu discovery
APIs Linux 2.2 offers. Doing magic fragmentation hacks would just cause
problems. In case you updated the MTU and the stack does not know about
it yet it is reasonable to use ip_local_error and simply drop it [there
are even some cases in the regular stack where this can happen - ever
seen the "sending pkt_too_big to self" message?]
For IPv6 this is even more important, because IPv6 only have end2end
fragmentation and strongly encourages pmtu discovery.
In short the big MTU/MSS hack is unnecessary and evil.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/