On Thu, Jul 20, 2000 at 09:44:20AM -0700, Greg Troutman wrote:
> Giles Lean wrote:
> > 
> > > just can't understand...  Something in the kernel config doesn't like
> > > chatting with these sites????  I don't know.  Help please.
> > 
> > Mmm ... as a wild guess, and assuming that 1.4.2 has this variable:
> > 
> >     # sysctl -w net.inet.tcp.rfc1323=0
> 
> I did this and it did not seem to help.  Though I get ->0 response, is
> it possible this will not take affect for a while???
> 
> > If you don't see a change, then it will be time to get out tcpdump.
> > But perhaps someone else can comment on those particular sites, too.
> 
> I just ran tcpdump on my ppp0 interface and tried to connect to
> http://www.ask.com, and here is the sum total output.  208.185.160.9 is
> www.ask.com.
> 
> ---------
> 09:32:48.121922 199.4.98.59.50666 > 208.185.160.9.www: S
> 2924857543:2924857543(0) win 16384 <mss 1460>
> 09:32:48.299051 208.185.160.9.www > 199.4.98.59.50666: S
> 739269912:739269912(0) ack 2924857544 win 8760 <mss 1460> (DF)

Note that 208.185.160.9 ansers with the DF bit set.
What's the MTU of you ppp interface (ifconfig ppp0 while ppp is running should
tell you) ?
Clearly the remote end is doing path MTU discovery, but some site are
missconfigured for this: their servers are configured to do path MTU discovery
but they block all ICMP packets, which breaks path MTU discovery (the remote
end thinks the packet is lost and tries to retransmit it as is, instead of
trying a smaller one).
Windows, and I think recent linux have path MTU discovery turned on.
The only "fix" you can do at your end is to bump the ppp mtu to 1500.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--