On 17/04/14 11:48, Toby Corkindale wrote:
On 16 April 2014 21:07, Keith Owens <kaos@ocs.com.au> wrote:
On 16/04/14 12:24, Toby Corkindale wrote:
Hi, I posted last year about a problem I was having with Linux's PPPoE functionality in regards to a specific modem. At the time I put it down to a dodgy modem and moved on, but now I've hit it on another modem, and twice seems more than coincidence.
The problem is that path MTU detection seem to break when the "bad" modems are involved. So the Linux box running pppoe is OK, because it knows the interface has an mtu+mru of 1492, but masqueraded clients do not. You can work around the problem a bit, by having an iptables rule with --clamp-mss-to-pmtu, but it's a kludge.. and importantly, only required for two of these four modems. The other two work just fine *with apparently identical configurations* (ie. LLC / bridged)
Can anyone think of a reason for this?
Wild guess - segmentation offload. I have seen offload do really strange things with masqueraded packets and it is just possible that the bad modems support offload but the good modems do not. On the linux box, issue
for interface in eth0 do for option in tso ufo gso gro lro do ethtool $interface $option off done done
Replace eth0 with all the physical network interface names (eth0 eth1 etc.). I don't have root shell access on the modems, so I can't run it there.
I experimented with adjusting ethernet options last time this came up in 2013, to no effect.
But thanks for the suggestion. Toby
Not on the modems, issue the commands on the Linux box. Offload is a negotiated attribute and if one end does not request offload, neither end will do it.