> [..] but some intermediate
> NAT/routers fix up this problem by dynamically modifiying the MSS option in
> initial TCP connections from client PCs. [..] What
> these NAT routers do is modify the TCP option for MSS during a SYN sequence
> to take into account the MTU size of the PPPoE interface, so as to avoid
> fragmentation, as well as PMTU blackhole problems.

Yes, I've seen that (and it worked). The rp-pppoe package (a userland PPPoE
implementation) has a "-m" option to do this.

I *could* *optionally* do this in my kernel pppoe interface as well, but I'd
like input from our in-depth TCP gurus on this first.

Actually (as the problem has been analyzed to be a broken IP Filter version
in -current) I have not seem anything breaking due to the MTU/fragmentation
when using a working IP Filter version.

So this option is of dubious value from my POV.

Without looking up the relevant standards I have a strong feeling that this
option would probably violate a *MUST NOT* statement in there.

Is this the case? Should we provide such an option?


Martin