Subject: Re: ADSL upstream problems on Sparc NetBSD 1.5
To: None <firstname.lastname@example.org>
From: Ignatios Souvatzis <email@example.com>
Date: 09/08/2001 19:35:41
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.
- 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.
- 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).