On Fri, Sep 07, 2001 at 07:40:54PM -0400, Sebastian Wain wrote:
> 
> I played with net.ipv4.ip_no_pmtu_disc, net.inet.ip.mtudisc, 
> net.inet.tcp_mss_ifmtu on the machine connected to the adsl modem.

wrong machine. Let me summarize what I've read on this same mailing list,
I think, or on news:comp.protocols.ppp

A. Description of the problem:

   - PPPoE provides an effective MTU of a couple of bytes less then 1500
   - some idiotic service providers (e.g. T-Online, from hearsay) do NOT
     create the appropriate "packet too big" ICMPs to their upstream, while
     their upstream nowadays certainly has a MTU of 1500, thus breaking 
     path MTU discovery.

   - you have a machine at your local Ethernet, NATted through your PPPoE
     gate. Becasue it thinks it is connected to a mtu=1500 LAN, it will 
     advertize, per default, a bit tcp segment size on connection opening.
     your peer will eventually send you 1500 byte packets.

   - your PPPoE gate can't do anything - it won't see the broken packet, as 
     it either is discarded at the far end, or discarded as broken when it
     enters your PPPoE interface.

B. Workaround: 

   - tell the _local machine_ (NOT the PPPoE NAT gate!) to advertize a smaller
     tcp segment size - which will make the far end of the TCP connection 
     send smaller segments in smaller packets that aren't broken by your 
     providers' PPPoE gete.

C. Solution: 
   - get a real provider. Unfortunately, a lot don't care because they target
     their PPPoE service at _single machine_ customers, who don't have the
     problem because the PPPoE interface has a (1500 - sizeof(PPPoE header))
     MTU, so they will automagically advertize a smaller TCP  segment size,
     and not see big packets for the majority of applications (which are 
     WWW over TCP, WWW over TCP, WWW over TCP, POP over TCP and SMTP over TCP).

Regards,
	Ignatios