> Martin seemed to indicate it wouldn't happen inside (non-rp) pppoe and
> that he though ipfilter was the place for it.

Yes - I think it is not in -current and I think it does not belong into
the PPPoE implementation.

It is not PPPoE related at all, just MTU < typical ethernet MTU related.
It happens for most kind of tunnels as well, but most of the time is not
discovered there because the tunnel endpoint is within a sane environment.

There has been discussions about it and someone said he's working on it.
I don't think it is integrated yet, and der Mouse wasn't sure about this
either.

If I would have to do it I'd implement a per-route optional max-MSS (similar
to the route MTU) and clamp to that in ip_output (all optionally, of course,
as this burns serious CPU cycles). And it needs to go into the fastforward
path in ipfilter. In the special case of a NAT router, it is important to
avoid recalculating the checksum twice (once for MSS clamping, second time
for NATed addresses). I have no idea how that could easily be done without
violating abstractions in the relevant code paths (but then I know nothing
about ipfilter internals).


Martin