On 2021/03/16 13:59, Klemens Nanni wrote: > On Tue, Mar 16, 2021 at 06:08:00AM -0600, Todd C. Miller wrote: > > I think it is helpful to tell the user what happens if the remote > > endpoint doesn't support RFC 4638. > The manual section basically says that already (last sentence): > > MTU/MSS ISSUES > Problems can arise on machines with private IPs connecting to the > Internet via a machine running both Network Address Translation (NAT) and > pppoe. Standard Ethernet uses a maximum transmission unit (MTU) of 1500 > bytes, whereas PPPoE mechanisms need a further 8 bytes of overhead. This > leaves a maximum MTU of 1492. pppoe sets the MTU on its interface to > 1492 as a matter of course. > > It doesn't hurt however to mention the specific message such that users > can tell *when* that happens; perhaps add it under DIAGNOSTICS as the > various wifi driver manuals, e.g. athn(4) do?
That one's a different thing entirely: pppoe has mtu 1492, lan and servers have 1500, tcp negotiates 1500, unless "fragmentation needed" messages make it through there are problems. i.e. this relates to packets carried inside pppoe, not the pppoe packets themselves. (Actually the mention of NAT here is wrong I think, same can apply with no-nat). Besides that, you have "rfc4638 negotiated but the path between endpoints is not clean" (old caveats case) and "rfc4638 attempted but other side says no" which is what Todd's adding.
