On 17/04/14 11:48, Toby Corkindale wrote: > On 16 April 2014 21:07, Keith Owens <[email protected]> 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. _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
