Subject: Re: pppoe problem
To: Christopher Vance <email@example.com>
From: Martin Husemann <firstname.lastname@example.org>
Date: 12/16/2001 13:26:05
> 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
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).