On 2016-09-14, Harald Dunkel <ha...@afaics.de> wrote: > > Hi folks, > > On 09/13/2016 02:58 PM, Stuart Henderson wrote: >> >> See "MTU/MSS ISSUES" in pppoe(4). >> > indeed, its documented, but its also a little bit misleading. > Reading the man page I had the first impression that modifying > the mtu and max-mss are equally effective. Apparently they > are not. > > AFAIU setting the max-mss affects TCP traffic only (e.g. > HTTPS). It defines the maximum payload block size on sending > and receiving(!) data via TCP. UDP and other protocols are not > affected. Very important to know if you run IPsec or openvpn > or other non-TCP protocols over the PPPoE tunnel. > > The mtu works on ethernet level, giving the maximum packet > size to send(!) to the next hop without fragmentation, > regardless if the higher level protocol is TCP, UDP, ESP or > whatever.
You are supposed to be able to get large packets through; routers are meant to either fragment or send ICMP "frag-needed" messages to allow the end host to do it. But some idiots misconfigure their firewalls to drop the necessary ICMP messages causing breakage to some sites. In practice, people configuring non-TCP services often try to keep packets below the common breakage points (especially 1492).. > Point is, setting the MTU does not affect the data flow from > the peer back to your site. AFAIU this made the difference > in this case. Reducing the max-mss seems to be a workaround > for some networking issue I cannot fix. The MSS in the TCP handshake is based on the MTU on the outgoing route from the end host. So if you have router - pppoe0 - 1492 router - internal - 1500 host - internal - 1500 the host will base its calculation on 1500 not 1492. "scrub (max-mss ..)" will cap this in the TCP handshake (and adjust checksums to match). However: if you have working 1500 MTU pppoe via baby jumbos on the ethernet interface, "scrub (max-mss..)" shouldn't fix anything. The restricted MTU is usually towards the "client" side of things rather than towards the server, plus if it's towards the server then many people will be affected so it's easier for the server admin to spot problems. > My current configuration uses both baby jumbo frames (mtu = 1508 > on re0 and mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for > TCP traffic on pppoe0 (1500 bytes - 40 bytes TCP/IP header - > 8 bytes PPPoE frame). You should not need both. If baby jumbos are working correctly (you can "ping -D -s 1472 $some_internet_host" from an end host) then you should be able to get rid of the scrub. If they are not working correctly, you should get rid of the baby jumbo config and just use 1492, this will at least fix things for larger packets in the normal case where there is no bad firewall config in the way.
